Skip to content
Project dossierE-commerce · Integration · B2B · Small business

A B2B shop for Spyk Bänder AG —
the ERP stays the leading system.

01 · Starting point

Spyk Bänder supplies customers who buy on terms: tiered prices, individual discounts, agreements that have grown over the years. That is exactly what makes a B2B shop demanding — it has to show every visitor the price that applies to them, and that logic lives in the ERP, not in the shop. So the task was not to build a shop but to get two systems to tell the same truth.

02 · Challenge

A B2B shop that accepts the ERP as the leading system: the customer base with its price groups and terms out of Avista, several contact people per company, customer-specific discounts without price upkeep per customer, orders written back to the ERP — and all of it bilingual throughout, for German-speaking Switzerland and the Romandie.

03 · Decisions

Shopware 6.7 as the shop, n8n as a reconciliation layer of our own, Avista stays in the lead. The field mappings live in maintained tables rather than in code — if a mapping changes, a table row changes. Discounts run through Shopware's own promotion logic: the customer carries their discount rate as an attribute, and the rules apply by themselves.

04 · What we did

A customer base grown over years brings the same question to every migration: which record is the same customer? We reviewed the whole base and put every ambiguous case up individually instead of merging automatically. That costs time before the migration — and saves it many times over afterwards.

05 · Result

A B2B shop in which prices, customers and orders all come from one source — no duplicate data upkeep, no price lists that drift apart.

Price and discount logic in the B2B shop
01
The customer signs in
Email address as the account, customer number as the company link.
02
The ERP supplies the terms
Price group, discount rate and payment terms come from Avista.
03
The rule applies by itself
The discount rate is an attribute of the customer — the promotion logic does the maths, with no price upkeep per customer.
04
The order goes back to the ERP
With customer number and contact person — the company-wide view stays in Avista.
Fig. 01 — Customer-specific prices without price upkeep per customer (schematic)
Integration architecture
Avista
ERP · the leading system
n8n
Reconciliation layer · Mapping tables
Shopware 6.7
B2B shop · DE/FR
Fig. 02 — Integration architecture (schematic)

Techno­logies used

Shopware 6.7B2B storefront with customer groups and promotion logic for discount tiers.
AvistaInventory management — the leading system for customers, articles, prices and terms.
n8nA reconciliation layer of our own: it reads Avista, translates, and writes through the Shopware API — repeatable and logged.
Mapping tablesField mappings, colour codes and price groups in maintained tables rather than in code.

What we took away

Migration is the moment data becomes visible. What nobody noticed for years is suddenly there in a list. Use that moment and you start with a clean base — skip it and you take everything with you.

Repeatability beats a one-off import: a reconciliation that runs safely every day is worth more than a migration that works once.

Related articles
When a middleware pays off — and when it does notInsightComparing shop systemsInsightD2C: how companies benefit from direct salesInsight
Related work & services
Case study: ERP shop integration for Juwelier BockholtCase studyService: Websites, shops and visibilityServiceService: Integration and interfacesService

Should your shop accept the ERP as the leading system?

We will tell you which connection suits your inventory management — and what it costs to run.

Discuss the integration→
Assess risks · discuss the approach · weigh the effort — with the person who ran the project