Managing Magento Store Views with One Counterpoint Backend

Running several storefronts from a single retail system can simplify operations, but only when the boundaries between each store are clear. Magento gives retailers a flexible way to present different catalogues, languages, currencies, customer groups and promotions while Counterpoint remains the operational source for products, inventory and sales records. Learn more about Sportswear.html.

For Australian retailers, this arrangement is useful when a business serves several brands, regions or customer segments. A retailer might sell through separate sites for trade customers and consumers, operate distinct fashion and outdoor brands, or maintain different storefronts for metropolitan and regional fulfilment.

The key is to decide which information should be shared and which should vary by store view. Product stock may come from the same Counterpoint locations, while prices, descriptions, delivery rules and promotions can change according to the Magento website or store configuration.

This guide explains how to handle multi-store views in Magento with one Counterpoint backend, including data mapping, inventory controls, customer accounts, tax settings and daily processes. The approach also applies to businesses moving away from NCR Retail Online after its discontinuation and adopting Magento through a Counterpoint partner.

Define The Magento Store Hierarchy

Magento separates websites, stores and store views, and each level serves a different purpose. A website usually represents a commercial operation with its own customer accounts, checkout and pricing rules. A store groups catalogues within that website, while a store view generally controls presentation, such as language or localised content.

For example, one Magento website could support a consumer brand with separate store views for English and simplified Chinese content. A second website could serve wholesale buyers with different payment terms and product visibility. Keeping this structure deliberate prevents a minor content variation from becoming an unnecessary operational division.

A single Counterpoint database can feed multiple Magento websites when the integration maps each store to the correct catalogue, warehouse, customer type and price level. Before configuration begins, document the required relationship between Counterpoint entities and Magento scopes. Include product codes, departments, locations, customer classes, tax categories and fulfilment methods.

Decide What Counterpoint Owns

Counterpoint should generally remain the authority for operational data. This includes item numbers, stock quantities, store locations, purchasing information, inventory adjustments and, where applicable, retail pricing. Magento then receives that information through scheduled synchronisation or an integration service.

Magento is usually better suited to web-specific content. Its administrators can manage search-optimised copy, page layouts, product images, related products, merchandising rules and online-only promotions without changing the records used by point-of-sale staff.

Conflicts occur when the same field is edited in both systems. A staff member might change a product description in Magento while another updates the item in Counterpoint, resulting in an overwrite during the next import. Establish field ownership in writing, then restrict editing rights so the system of record remains clear.

Map Catalogues And Stock Locations

A shared catalogue is efficient when every storefront sells the same range. Separate catalogues are more suitable when brands or customer segments require different products. Magento can assign products to particular websites, allowing one Counterpoint item to appear on one site while remaining hidden from another.

Inventory mapping deserves special care. Counterpoint may track stock across a Sydney shop, a Melbourne warehouse and a Brisbane location, while Magento displays a single online quantity. Decide whether the online store can sell from all locations, from a dedicated warehouse, or from a pooled virtual source. Set safety stock thresholds to reduce overselling when shop-floor sales and online orders occur close together.

Australian delivery patterns can influence this decision. A retailer shipping to Perth, Hobart or remote parts of the Northern Territory may need stock reserved for longer delivery windows. Click and Collect can use local store inventory, while parcel orders may need to route through the warehouse with the best available quantity.

Product availability should also reflect real trading rules. If Counterpoint marks an item as discontinued, Magento should remove it from sale or display a controlled back-order message. Seasonal goods, such as school footwear or summer sportswear, can be published by store view while the underlying item remains in the shared inventory file.

Control Prices, GST And Customer Groups

Price synchronisation should account for the difference between a standard retail price and a Magento promotion. Counterpoint may provide the base price, while Magento applies a website-specific discount, coupon or customer-group rule. Avoid sending promotional prices back to Counterpoint unless the integration is designed to support that workflow.

Australian stores must also handle GST consistently. Prices displayed to consumers are commonly GST-inclusive, while business customers may expect tax details on invoices and credit notes. Configure Magento tax classes and display settings to match the accounting process used by the Counterpoint installation, and test rounding on products with low prices, bundles and mixed tax treatment.

A trade storefront might use negotiated price lists or minimum order quantities. If B2B accounts need approval, credit limits or purchase-order checkout, map those requirements to a defined customer group rather than duplicating customer records for every store view. Guidance on B2B account management can help shape the account workflow during migration.

Customer group assignments should be stable across synchronisations. A customer who buys from a retail site should not accidentally receive wholesale pricing because an email address matched a Counterpoint business account without the correct approval status.

Configure Domains And Store Presentation

Each storefront can use its own domain, subdomain or URL path, while the same Magento installation manages the underlying commerce functions. Distinct domains are useful for separate brands, whereas store views under one domain may be enough for language or presentation changes.

Use a consistent naming convention for websites, stores, store views and integration codes. Names such as consumer-au, trade-au and brand-b-sport are easier to identify than generic labels such as store1 and view2. The same convention should appear in deployment notes, API credentials and monitoring alerts.

Short campaign links and redirect rules should be managed carefully when several storefronts exist. A branded domain can make promotional URLs easier to recognise and maintain; this overview of custom short domains is relevant when planning campaign tracking across separate Magento sites.

Check that canonical URLs, XML sitemaps, robots rules and metadata are correct for every domain. A duplicated catalogue across store views can create search-engine confusion if Magento generates multiple indexable URLs for the same product without suitable canonical settings.

Manage Orders And Fulfilment Centrally

Orders from every Magento website should carry enough context for Counterpoint to identify the originating store, customer group, payment method and delivery option. Pass the Magento website or store code into the order record so staff can distinguish a trade order from a consumer purchase.

The integration should also define how cancellations, refunds and partial shipments move between systems. If a customer returns an online purchase to a physical store in Adelaide or Newcastle, staff need a reliable process for locating the order and recording the adjustment against the correct stock location.

Payment status must be separated from fulfilment status. An order can be paid but held for stock verification, address review or fraud screening. Once Counterpoint accepts the order, Magento should receive the relevant status update and send the customer an accurate notification.

Delivery choices may differ by store. One brand might offer Australia Post and courier delivery, while another supports local pickup only. Use website-specific shipping rules and confirm that freight charges, estimated delivery dates and tracking messages remain appropriate for each region.

Test Synchronisation And Daily Operations

Testing should begin with a small group of products and customers before a full catalogue import. Check product creation, updates, stock reductions, price changes, customer registration, order export, refunds and invoice data. Repeat the tests for every Magento website and store view, because a configuration that works for one scope may fail in another.

Pay particular attention to concurrent sales. Sell an item through Counterpoint, Magento and a physical shop within a short period, then confirm that stock adjustments reach every channel. Test failed API calls, duplicate orders and delayed imports as well as successful transactions.

Staff need a practical operating procedure for exceptions. It should explain who investigates a stock mismatch, how to pause a product, when to re-run an import and how to handle an order that exists in Magento but not in Counterpoint. Logs should include timestamps, item codes, order IDs and the affected website.

Security controls matter across the whole connection. Use separate integration credentials, least-privilege permissions, encrypted transport and restricted administrator access. Review logs for unusual exports or repeated authentication failures, and avoid storing payment card data in either platform.

The most reliable setup treats Magento as the customer-facing commerce layer and Counterpoint as the shared retail operations engine. Define ownership for every field, map inventory locations carefully, separate store-specific pricing from core item data, and test every website before launch. In practical terms, begin with a written data map and one pilot storefront, then expand only after stock, tax and order flows reconcile cleanly.