ERP, PIM und Shop fachlich verbinden
Ein vollständiger Export garantiert noch keine richtige Übernahme.
Umfang vor Umsetzung
Ein vollständiger Export garantiert noch keine richtige Übernahme. Eloquin plant Shop-Schnittstellen und Migrationen anhand von Datenhoheit, stabilen Kennungen, Varianten und Bestellzuständen. Fachliche Zuordnung, kontrollierte Probeläufe und ein dokumentierter Abgleich machen sichtbar, welche Daten tatsächlich im Ziel angekommen sind.
Für Identität, Preise, Bestand, Beschreibung und Versandstatus kann jeweils ein anderes System verantwortlich sein. Ein eindeutiger Schreibweg verhindert, dass eine Änderung zwischen zwei Systemen hin- und herüberschrieben wird.
Ein Vaterprodukt ist nicht automatisch eine bestellbare Variante. Bestellpositionen, Mengen, Sprache, Medien, Preise und Währungen brauchen eigene Zuordnungen. Offene Felder und nicht übernehmbare Werte werden benannt, nicht still verworfen.
Authentifizierung, Version, Übertragung und Bestätigung gehören zum Vertrag. Teilfehler, veraltete Nachrichten und Wiederholungen erhalten Regeln, ein Protokoll und eine zuständige Person. Betriebsüberwachung ist ein ausdrücklich zu vereinbarender Umfang.
Website-Schnittstellen und Datenmigration behandeln redaktionelle Inhalte und Websiteübergaben. Hier stehen Handelsobjekte und ihre Folgewirkungen im Mittelpunkt. Die E-Commerce-Strategie entscheidet über Angebot und Betriebsmodell; ein neuer Shop oder eine neue Warenwirtschaft ist nicht automatisch Teil dieses Datenauftrags.
Ein ausgefüllter Abgleich
FL-KLAR mit zwei bestellbaren Varianten: FL-050 für 0,5 Liter und FL-075 für 0,75 Liter. Die Kennungen sind Modellwerte, keine Produkte von Eloquin.ALT-B-501 enthält zwei FL-050 und eine FL-075: zwei Positionen, drei Einheiten. Auftrag ist in Bearbeitung, Zahlung bezahlt und Versand offen. Es werden keine echten Personen- oder Zahlungsdaten gezeigt.Die Zuordnung hat vier Spalten. Auf schmalen Bildschirmen können Sie den folgenden Bereich horizontal scrollen; er ist auch per Tastatur fokussierbar.
| Quelle | Fachliche Bedeutung | Regel im Ziel | Abnahme |
|---|---|---|---|
| FL-KLAR | Gemeinsames Produkt, nicht selbst bestellbar | Vaterprodukt anlegen oder anhand gespeicherter Quellzuordnung aktualisieren | Genau ein Vater mit beiden Varianten; keine zusätzliche verkaufbare Sammelvariante |
| FL-050 / FL-075 | Zwei getrennte Artikel mit 0,5 / 0,75 Liter | Je eine stabile Quell-ID, eindeutige Artikelkennung und Zuordnung zu FL-KLAR | Beide bestellbaren Varianten mit korrekter Auswahl; keine Zuordnung allein über den Produktnamen |
| Revision 42: 8 / 5 | Verkaufbare Bestandswerte nach Quellberechnung | Als vereinbarte Bestandswerte übernehmen; identische Revision nicht erneut als Abgang verbuchen | Im Modell bleiben 8 und 5 nach dem ersten und wiederholten Lauf gleich |
| ALT-B-501 | Eine historische Bestellung, zwei Positionen, drei Einheiten | Quellauftrag und Zielauftrag dauerhaft zuordnen; Mengen 2 × FL-050 und 1 × FL-075 erhalten | Genau ein Auftrag; erneuter Lauf erzeugt weder zweiten Auftrag noch neue Zahlung |
| In Bearbeitung / bezahlt / offen | Auftrags-, Zahlungs- und Versandzustand sind getrennt | Jeweils passende Zielzustände und erlaubte Übergänge bestimmen | Bezahlt bedeutet nicht versendet; nach Übernahme bleiben Zahlung und Lieferung unterscheidbar |
| Vorhandene Shopbeschreibung | Im Shop gepflegter Inhalt | Beim Bestandsimport nicht überschreiben | Text bleibt erhalten; fehlender ERP-Text löscht keine freigegebene Shopbeschreibung |
Erwartete Struktur: ein Vaterprodukt, zwei bestellbare Varianten, eine historische Bestellung, zwei Bestellpositionen und drei bestellte Einheiten. Die aktuellen Bestandswerte bleiben separat acht und fünf; sie werden nicht mit Bestellmengen zu einer bedeutungslosen Gesamtsumme addiert.
Freigabe: Erst wenn Kennungen, Beziehungen, Zustände und wiederholter Lauf passen, kann dieser Modellumfang als technisch geprüft protokolliert werden. Unbekannte Artikel und unklare Bestätigungen bleiben offene Fehler; ein Teilimport wird nicht als vollständiger Erfolg dargestellt.
Nicht enthalten: Preis-, Steuer-, Rabatt- und Belegmigration, Kundenkontoübernahme sowie URL-Weiterleitungen. Diese Gegenstände brauchen im tatsächlichen Auftrag eigene Regeln und Abnahmen. Das Beispiel belegt keine bereits ausgeführte Migration.
Auch Änderungen nach dem ersten Export beachten
Datenobjekte, Kennungen, Feldhoheit und Nebenwirkungen festlegen. Geeignete synthetische oder ausdrücklich freigegebene Testdaten verwenden; keine unkontrollierten Zahlungs- oder Versandaktionen auslösen.
Übernahme, Teilfehler, Wiederholung und Gegenproben dokumentieren. Umfang und fachliche Bedeutung prüfen, nicht lediglich die Zahl erfolgreich verarbeiteter Zeilen.
Schreibstopp oder kontrollierte Änderungsübernahme vereinbaren. Neue Bestellungen und Bestandsänderungen bis zur Freigabe abgleichen; einen Rückwechsel nur mit definiertem Datenweg durchführen.
Shopware zeigt beispielhaft, warum Bestell-, Zahlungs- und Lieferzustände getrennt betrachtet werden. Die konkrete Zuordnung hängt von beiden Systemen ab. Die Shopware-Entwicklung behandelt die Plattformumsetzung; E-Commerce-SEO die Auffindbarkeit von Shopseiten. Für veränderte URLs hilft der Artikel bestehende URLs beim Relaunch erhalten; er ersetzt den Transaktionsabgleich nicht.
Sie erhalten im vereinbarten Umfang Objekt- und Feldmapping, technische Verbindung beziehungsweise Migrationsablauf, Fehler- und Abgleichprotokoll sowie Wechsel- und Übergabeplan. Ein bestimmter störungsfreier Zeitraum oder eine unterbrechungsfreie Umschaltung wird ohne Prüfung nicht zugesagt.
Gut zu wissen
Eine Schnittstelle überträgt Daten wiederkehrend nach vereinbarten Auslösern oder Takten. Eine Migration übernimmt einen festgelegten Bestand in ein neues Ziel und muss auch Änderungen bis zum Wechsel berücksichtigen. Beide brauchen klare Kennungen und Fehlerregeln; Abgleich und Übergabe unterscheiden sich je nach Vorhaben.
Nein. Benötigter Umfang, Datenmodell, zulässige Verarbeitung und verfügbare Zielmechanismen werden vorher geprüft. Historische Bestellungen können ein Archivthema sein statt eines aktiven Imports. Passwörter, Zahlungstoken und Zahlungsaufträge werden nicht als beliebige übertragbare Textfelder behandelt.
Für den fachlichen Vorgang werden stabile Quellkennungen und gespeicherte Zielzuordnungen vereinbart. Ein erneuter Versuch muss den vorhandenen Vorgang erkennen. Der Nachweis erfolgt auch für unklare Bestätigungen und Teilfehler; die bloße Bezeichnung einer API als zuverlässig genügt nicht.
Der Wechselplan hält fest, welches System Bestellungen und Bestände führt, wie neue Vorgänge erhalten bleiben und wann ein Rückwechsel noch vertretbar ist. Ein altes Datenbankbackup darf nicht pauschal über inzwischen entstandene Bestellungen geschrieben werden. Der konkrete Datenabgleich wird vor der Freigabe erprobt.
Ihr Vorhaben einordnen
Nennen Sie Quell- und Zielsystem, die zu übertragenden Objekte und den Anlass: laufende Verbindung oder Wechsel. Ungefähre Datenmengen und bekannte Fehler helfen bei der Einordnung. Senden Sie zunächst keine Kundendaten, Bestellexporte oder Zugangsdaten.
