Integrated Web Shops

The system decision comes first, and it depends less on the shop itself than on everything around it. We use WooCommerce when shop and website should live in the same backend and you want to keep control over code and hosting. Shopify fits when running your own infrastructure is not the goal. Shopware becomes relevant with larger assortments and deep category trees, SAP Commerce Cloud where an SAP landscape is already in place.

Then comes the work that actually takes the time. We model the product structure with variants, attributes and units of measure, set up tax classes and delivery countries, configure payment methods and shipping rules, and connect the payment provider. Which payment methods make sense depends on assortment and market: invoice, direct debit, cards and wallets behave differently in accounting and reconciliation. Orders, customers and stock levels are handed to the ERP, through an API or a middleware service, depending on what your system supports.

Before launch we test the full order path with live payment methods, check invoice and shipping documents, and hand over documentation your team can use to create products without us. That includes a test return, because errors in cancellations and credit notes otherwise surface in live operation.

An integrated shop pays off when products and content belong together. A manufacturer showing datasheets, application examples and spare parts on one site loses exactly that connection once the shop sits on a separate subdomain. The same applies if you publish guides and want readers to move from an article straight into the cart. A separate shop system means maintaining navigation, tracking and legal texts twice.

The second common trigger is manual work in the background. Orders arriving by email and retyped into the ERP, prices maintained in three spreadsheets, stock levels that are only correct the next morning: that is less a shop problem than an integration problem. In projects like these the shop is the smaller piece of work and the integration is the larger one.

It is not the right path if you sell a handful of items occasionally. A form and a payment request will often do. Selling spare parts to existing customers rarely needs a full shop either, an order form inside the customer account is usually enough. Building your own installation also makes little sense if your assortment runs entirely through marketplaces.

Most shop projects stumble over data, not technology. When article numbers follow no rule, variants are kept as separate products, or units of measure are named differently in the ERP than in the catalog, every import has to be done twice. So we settle early which system is the leading source for prices, stock and master data, and in which direction each field synchronizes. The result is a field mapping that records which shop field corresponds to which ERP field.

For larger assortments a PIM between ERP and shop is worth the effort. The ERP owns price, stock and article number, the PIM manages descriptions, images, translations and category assignments. The shop becomes an output channel rather than a data store. Without a PIM that content lives in the shop, which holds up as long as there is only one sales channel.

Other points to settle early:

• Whether prices are held net or gross, and how rounding is handled
• Which payment methods you actually need and which you can skip
• How shipping is calculated: by weight, zone or order value
• Who books returns and cancellations, in the shop and in the ERP