Bagisto behandelt einen E-Commerce-Katalog nicht als eine flache Sammlung aus Products und benutzerdefinierte Felder. Die Laravel-basierte Architektur trennt Produkttypen, Produktattribute, Attributfamilien, Categories, Channels, Locales, Währungen, Bestandsquellen, Customer-Gruppen, Orders, CMS Pages, Marketingdatensätze, Packages, APIs und optionale Commerce-Ebenen wie Marketplace- oder B2B-Funktionen. Ein Quellfeld ist in Bagisto deshalb erst dann wirklich nutzbar, wenn es in der Struktur ankommt, die seine geschäftliche Bedeutung trägt.
Diese Trennung verändert den Migrationsumfang. Ein Größenwert kann reine Beschreibung, filterbares Attribut oder Teil einer konfigurierbaren Product-Beziehung sein. Eine Menge kann einer bestimmten Bestandsquelle gehören, statt global für das Product zu gelten. Ein Storefront kann einem Bagisto-Channel mit eigener Root Category, Locale, Währung, Theme und Bestandszuordnung entsprechen. Ein Unternehmenskonto oder Verkäuferdatensatz kann von einem installierten Bagisto-Package abhängen und nicht vom Kernmodell für Customers.
Die zentrale Frage lautet daher nicht, ob Bagisto ein Feld mit ähnlicher Bezeichnung besitzt. Entscheidend ist, ob der Zielshop dieselbe Beziehung abbildet: Wem gehört der Datensatz, was steuert er und welche anderen Datensätze müssen verbunden bleiben, damit die migrierten Daten ihre geschäftliche Bedeutung behalten?
Bagisto ordnet Datensätze verschiedenen Commerce-Ebenen zu
Bagisto verbindet Kernobjekte des Commerce mit Konfiguration und erweiterungseigenen Strukturen. Zwei Werte, die in einem Export direkt nebeneinander stehen, können im Ziel unterschiedlichen Ebenen gehören. Die Product-Identität gehört in den Katalog. Welche Felder für ein Product verfügbar sind, wird durch seine Attributfamilie bestimmt. Der Storefront-Kontext gehört zu Channels. Die Bestandsverantwortung liegt bei Bestandsquellen. Customer-Segmentierung gehört zu Customer-Gruppen oder zu einer installierten B2B- beziehungsweise Marketplace-Ebene. Darstellung kann in CMS Pages, Themes oder einem Headless-Storefront liegen.
| Bedeutung im Quellsystem | Wahrscheinlicher Eigentümer in Bagisto | Konsequenz für die Übertragung |
|---|---|---|
| Verkaufbarer Artikel | Product mit definiertem Produkttyp | Der Produkttyp bestimmt untergeordnete Datensätze, Kaufoptionen, Auftragsabwicklung und Preisverhalten. |
| Produktspezifikation | Attribut innerhalb einer Attributfamilie | Ein sichtbarer Textwert ist nicht automatisch filterbar, vergleichbar oder wiederverwendbar. |
| Store, Markt oder Domain | Channel mit Locale, Währung, Root Category, Theme und Bestandsbeziehungen | Der Storefront-Umfang muss am richtigen Katalog- und Lokalisierungskontext hängen bleiben. |
| Lagerbestand | Zuordnung zu einer Bestandsquelle und Menge | Eine globale Bestandszahl kann die Zugehörigkeit zu einem Standort verlieren. |
| Customer-Segment | Customer-Gruppe oder Package-eigene Kontostruktur | Preis- und Zugriffslogik lässt sich möglicherweise nicht in einem einzigen Customer-Feld ausdrücken. |
| Historischer Verkauf | Order mit Positionen, Summen, Adressen, Rechnungen, Sendungen, Erstattungen und Transaktionen | Eine Order-Anzahl allein erhält keine geschäftlich nutzbare Historie. |
| Individuelles Commerce-Verhalten | Bagisto-Package, individuelles Modul, API-eigener Datensatz oder externes System | Reines Feld-Mapping reicht nicht, wenn eine andere Komponente die Beziehung besitzt. |
Diese mehrschichtige Eigentümerschaft ist der Grund, warum eine direkte Eins-zu-eins-Zuordnung nach Feldnamen unzuverlässig ist. Derselbe Quellwert kann in Bagisto an unterschiedliche Ziele gehören, je nachdem, ob er Product-Auswahl, Katalogverwaltung, Lokalisierung, Bestand, Kontobehandlung, Reporting oder Integrationskontinuität beeinflusst.
Produkttypen definieren verkaufbare Beziehungen
Bagisto unterstützt mehrere Produkttypen, darunter einfache, konfigurierbare, virtuelle, Bundle-, gruppierte, herunterladbare und buchungsbezogene Products. Der Produkttyp ist nicht nur eine Verwaltungsbezeichnung. Er bestimmt, was verkauft wird, ob Child- oder verknüpfte Products existieren, welche Felder sinnvoll sind, wie Preis und Bestand interpretiert werden und was der Käufer auswählt.
Ein Parent Product mit Farb- und Größenvarianten kann in ein konfigurierbares Product überführt werden, dessen Variationen eigene SKUs, Preise, Mengen, Bilder oder Sichtbarkeit besitzen. Ein Kit passt nur dann in ein Bundle, wenn Komponenten und Auswahlregeln mit Bagistos Bundle-Beziehung übereinstimmen. Ein gruppiertes Product ist eine Zusammenstellung verknüpfter eigenständig verkaufbarer Products und nicht eine einzelne bestandsführende SKU. Ein herunterladbares Product benötigt Datei- und Zugriffsbeziehungen. Ein buchungsbezogenes Product ergänzt Verfügbarkeits- und Terminlogik, die in einer gewöhnlichen Product-Zeile nicht existiert.
| Muster im Quellsystem | In Bagisto zu unterscheidende Beziehung | Auswirkung auf den Umfang |
|---|---|---|
| Parent Product mit Child-SKUs | Konfigurierbares Product und Variationen | Parent-Inhalte und kommerzielle Werte der Variationen dürfen nicht zusammengeführt werden. |
| Kit mit optionalen Komponenten | Bundle Product und Bundle-Auswahl | Auswahl, Menge und Preis der Komponenten können eine strukturelle Übertragung erfordern. |
| Merchandising-Gruppe eigenständiger Artikel | Gruppiertes Product und verknüpfte Products | Jedes verknüpfte Product bleibt eigenständig verkaufbar und bestandsführend. |
| Nicht-physische Leistung | Virtuelles Product oder Package-eigene Servicestruktur | Versand- und Auftragsabwicklungslogik unterscheiden sich von physischen Products. |
| Digitaler Artikel | Downloadable Product, Dateien, Links und Zugriffsregeln | Die Dateibeziehung ist von Product-Texten getrennt. |
| Terminbasierte Leistung oder Vermietung | Booking Product oder individuelle Package-Struktur | Verfügbarkeit und Ressourcen lassen sich nicht als einfache Optionen darstellen. |
Die Entscheidung zum Produkttyp beeinflusst auch historische Orders. Eine Order-Position muss weiterhin verständlich bleiben, selbst wenn der Zielshop das Product anders modelliert als der Quellshop. Nur den ursprünglichen Product-Namen zu erhalten, ohne gewählte Variation, Bundle-Auswahl, Download- oder Buchungskontext zu bewahren, würde eine technisch vorhandene, aber semantisch unvollständige Bestellhistorie erzeugen.
Attribute und Attributfamilien steuern die Katalogbedeutung
Bagisto-Attribute definieren strukturierte Product-Informationen. Attributfamilien gruppieren die Attribute, die für eine Product-Klasse verfügbar sind. Deshalb können benutzerdefinierte Felder eines Quellkatalogs nicht ungeprüft in ein einziges universelles Bagisto-Product-Schema kopiert werden.
Ein Feld, das zum Filtern dient, braucht eine andere Behandlung als ein Feld, das nur intern referenziert wird. Ein Wert, der eine konfigurierbare Auswahl erzeugt, muss von rein beschreibenden Spezifikationen unterschieden werden. Ein lokalisierter Titel, ein Preis, eine eindeutige SKU, ein boolescher Storefront-Schalter und eine technische Multi-Select-Spezifikation haben nicht denselben Eingabetyp, dieselbe Validierung, Indexierung oder Channel- und Locale-Bedeutung.
Die Gestaltung der Attributfamilien übersetzt damit die Katalogkonventionen des Quellshops in ein gesteuertes Schema des Zielshops. Ein Händler mit Bekleidung, Maschinen, herunterladbaren Handbüchern und buchbaren Leistungen kann getrennte Familien benötigen, weil jede Product-Gruppe andere Attribute und Geschäftsbeziehungen verlangt.
| Verhalten des Quellfelds | Interpretation in Bagisto | Was erhalten bleiben muss |
|---|---|---|
| Käufer wählt den Wert | Konfigurierbares Attribut oder produkttypspezifische Auswahl | Der gewählte Wert identifiziert die richtige verkaufbare Variation oder das richtige Ergebnis. |
| Shopper filtert nach dem Wert | Filterbares Product-Attribut | Werte bleiben ausreichend normalisiert für sinnvolle Filterung. |
| Mitarbeitende vergleichen Products anhand des Werts | Vergleichbares oder strukturiertes Attribut | Gleichartige Fakten bleiben nicht in Beschreibungen verborgen. |
| Feld gilt nur für eine Product-Klasse | Einer bestimmten Familie zugeordnetes Attribut | Nicht betroffene Products werden nicht in ein überladenes Universalschema gezwungen. |
| Wert unterscheidet sich nach Locale oder Channel | Lokalisierbare oder Channel-bezogene Daten, sofern unterstützt | Der richtige Storefront-Kontext erhält den richtigen Wert. |
| Wert ist interne Integrationsmetadaten | Custom Attribute, Package-Datensatz oder externe Kennung | Operative Kennungen werden nicht veröffentlicht oder als Storefront-Inhalt umfunktioniert. |
Diese Trennung verhindert eine typische Migrationsverzerrung: jede Quelloption, Spezifikation, jedes Tag, App-Feld und jeden internen Code als denselben Attributtyp zu behandeln. Bagisto kann umfangreiche Product-Daten aufnehmen, doch diese Flexibilität ist nur dann wertvoll, wenn jede Information der passenden Familie und Funktion zugeordnet wird.
Categories, Channels, Locales und Bestandsquellen bilden den Storefront-Kontext
Bagisto-Categories organisieren Products, aber Channel-Beziehungen bestimmen, welchen Katalog- und Lokalisierungskontext ein Storefront verwendet. Ein Channel kann Hostname, Root Category, Locales, Währungen, Theme und Bestandsquellen-Zuordnungen tragen. Ein Quellshop, regionaler Katalog, Sprachshop oder Storefront einer Geschäftseinheit kann daher mehr darstellen als nur einen Category-Baum.
Categories können Käufernavigation, Merchandising-Landingpages, interne Klassifikation oder geerbte Altstruktur darstellen. In Bagisto sollten die weiterhin nützlichen Beziehungen erhalten werden und nicht lediglich alle historischen Category-Bezeichnungen. Besonders wichtig ist die einem Channel zugewiesene Root Category, weil sie den obersten Katalogbereich dieses Storefronts definiert.
Bestandsquellen fügen eine eigene Eigentumsdimension hinzu. Ein Product kann Bestand über mehrere Standorte verteilen. Die Quellmenge muss deshalb zusammen mit Lager-, Filial-, Lieferanten-, Abhol- oder Fulfillment-Kontext gelesen werden. Alle Standorte in einer Zahl zusammenzufassen kann die Gesamtmenge erhalten und gleichzeitig die standortbezogene Verfügbarkeit zerstören.
| Umfangsebene | In Bagisto getragene Beziehung | Typische Unklarheit im Quellsystem |
|---|---|---|
| Category | Parent-Child-Hierarchie, Product-Zuordnungen, lokalisierte Inhalte und URL-Bedeutung | Quell-Categories können Navigation, SEO und interne Gruppierung vermischen. |
| Channel | Domain, Root Category, Locale, Währung, Theme und Bestandsquellen-Kontext | Ein Quell-„Store“ kann tatsächlich Markt, Sprache, Marke oder Geschäftseinheit darstellen. |
| Locale | Übersetzte Product-, Category- und Inhaltswerte | Sprachvarianten können als doppelte Datensätze oder feldbezogene Übersetzungen vorliegen. |
| Währung | Anzeige- und Preiskontext | Quellwährungen können feste Preise, Umrechnung oder marktspezifische Preisgestaltung darstellen. |
| Bestandsquelle | Standort, Menge und Verfügbarkeitsverantwortung | Eine Bestandszahl ohne Standort kann nicht zuverlässig einer Quelle zugeordnet werden. |
Die Migration sollte zuerst bestimmen, welche dieser Beziehungen tatsächlich geschäftlich relevant sind. Ein historischer Store-Name ist keine ausreichende Grundlage für einen neuen Channel. Ebenso rechtfertigt eine alte Sprachspalte nicht automatisch eine eigene Locale, wenn Inhalt, URL und Katalogkontext anders organisiert werden.
Customer- und B2B-Strukturen können mehr als ein Konto darstellen
Bagistos Kernmodell für Customers unterstützt Konten, Adressen und Gruppen. Marketplace-, B2B- oder andere Packages können zusätzliche Organisationen, Verkäufer, Rollen, Kataloge, Freigaben, Quotes, Kreditinformationen oder andere Beziehungen ergänzen. Deshalb sollte ein Quellkonto nicht automatisch als ein einzelner Customer-Datensatz behandelt werden.
Ein B2B-Unternehmen kann mehrere Benutzer und Rollen enthalten. Ein Marketplace-Verkäufer kann Products, Orders, Provisionen und Auszahlungen besitzen. Ein Customer kann gleichzeitig einer Gruppe für Preis- oder Zugriffslogik angehören. Ein externes CRM kann wiederum die führende Account-ID besitzen. Diese Ebenen müssen getrennt betrachtet werden.
| Quellbedeutung | Mögliche Bagisto-Struktur | Zu erhaltende Beziehung |
|---|---|---|
| Einzelner Käufer | Core Customer und Adressen | Kontoidentität, Zugang, Kontakt- und Adresshistorie. |
| Preis- oder Zugangssegment | Customer-Gruppe | Gruppenmitgliedschaft und die Funktion, die davon abhängt. |
| Unternehmenskonto | B2B-Package-Struktur | Organisation, Benutzer, Rollen, Kataloge, Preis-/Freigabelogik und externe IDs. |
| Marketplace-Verkäufer | Marketplace-Package-Struktur | Verkäufer, Products, Orders, Provisionen, Auszahlungen und Status. |
| CRM-/ERP-Konto | Externe Kennung oder Integrationsbeziehung | Der Zielshop bleibt mit dem führenden externen Datensatz verknüpfbar. |
Eine erfolgreiche Migration erhält daher nicht nur Kundennamen und E-Mail-Adressen, sondern auch die Beziehungen, die Preis, Zugriff, Besitz und Kontohistorie erklären. Wenn ein Package diese Beziehungen besitzt, muss das Migrationsdesign dessen Schema und nicht nur den Core-Customer berücksichtigen.
Orders bewahren historische Geschäftsbeziehungen
Bagisto-Orders verbinden Positionen, Summen, Adressen, Rechnungen, Sendungen, Erstattungen und Transaktionen. Diese Strukturen beschreiben einen historischen Geschäftsvorgang. Sie sollten nicht aus aktuellen Product-, Customer-, Preis-, Steuer-, Zahlungs- oder Versandkonfigurationen neu berechnet werden.
Eine Order-Position kann den Zustand zum Kaufzeitpunkt widerspiegeln, obwohl sich das aktuelle Product oder der Customer später geändert hat. Werden historische Snapshots durch aktuelle Katalogwerte ersetzt, verändert sich die Geschichte. Umgekehrt sind importierte Summen ohne Positionen, Status und Dokumentkontext für Kundenservice und Reporting nur eingeschränkt nutzbar.
| Order-Beziehung | Historische Bedeutung |
|---|---|
| Order-Position | Product-Identität, SKU, Menge, Preis, gewählte Konfiguration und beschreibender Snapshot. |
| Adresse | Rechnungs- und Versanddaten zum Kaufzeitpunkt. |
| Rechnung | Anerkannter oder fakturierter Betrag, der sich vom Lifecycle-Status der Order unterscheiden kann. |
| Sendung | Auftragsabwicklung und versandte Mengen. |
| Erstattung | Rückgebuchter Wert und betroffene Positionen oder Beträge. |
| Transaktion | Referenz des Zahlungssystems und Statusnachweis, sofern vorhanden. |
| Order-Status | Bedeutung des Quell-Lifecycles, die einen bewusst gewählten Zielshop-Gegenwert erfordern kann. |
Der Migrationsumfang sollte genug Order-Detail erhalten, damit Kundenservice, Kontohistorie, Reporting und Abgleich mit externen Systemen weiterhin funktionieren. Aktuelle Zahlungs-, Versand-, Steuer- und Benachrichtigungslogik gehört zur Zielshop-Konfiguration; historische Bezeichnungen und Beträge gehören zum migrierten Order-Kontext.
CMS, URLs, Marketingdatensätze und Suchdaten haben getrennte Eigentümer
Bagisto umfasst CMS Pages, URL-Rewrites, Sitemaps, Suchbegriffe, Suchsynonyme, Newsletter-Abonnements, Reviews, Warenkorbregeln und Katalogregeln. Diese Datensätze sollten nicht in einen allgemeinen „Content“-Block zusammengeführt werden, weil sie unterschiedliche Aufgaben erfüllen.
CMS Pages tragen Seiteninhalt und URL-Identität. Product- und Category-Metadaten gehören zu ihren Katalogdatensätzen. URL-Rewrites erhalten Routenbeziehungen. Suchbegriffe und Synonyme beeinflussen die Produktsuche. Reviews gehören zu Customers und Products. Newsletter-Abonnements bilden Einwilligungs- und Zielgruppendaten ab. Warenkorb- und Katalogregeln kodieren Bedingungen und Aktionen und nicht nur Rabattwerte.
| Quellobjekt | Eigentümer in Bagisto | Grenze der Übertragung |
|---|---|---|
| Informationsseite | CMS Page | Inhalt, Route, Metadaten und Navigationsbeziehung sind getrennte Aspekte. |
| Product- oder Category-Metadaten | Katalogdatensatz | SEO-Felder müssen an der richtigen Entität und Locale hängen bleiben. |
| Alte URL oder Weiterleitung | URL-Rewrite- oder Redirect-Struktur | Alter Pfad und Zielbeziehung müssen explizit erhalten bleiben. |
| Suchsynonym | Suchsynonym-Datensatz | Ein Keyword-Paar ist kein gewöhnlicher Seiteninhalt. |
| Product Review | Product-Customer-Review-Beziehung | Bewertung, Autor, Status und Product-Zuordnung sind relevant. |
| Aktionsregel | Warenkorb- oder Katalogregel | Bedingungen, Aktionen, Zeiträume, Channels und Customer-Gruppen bilden gemeinsam die Regel. |
Marketingdatensätze reagieren besonders empfindlich auf semantische Verkürzung. Ein Quell-Coupon ohne Berechtigungsbedingungen, Laufzeit, Customer-Umfang, Nutzungshistorie oder Rabattaktion ist in Bagisto nicht dieselbe Promotion. Existiert keine gleichwertige Regelstruktur, sollte der Datensatz als historischer Nachweis erhalten oder als Zielshop-Konfiguration neu gestaltet werden, statt in ein irreführendes Direkt-Mapping gezwungen zu werden.
Packages, APIs, Headless-Storefronts und benutzerdefinierte Tabellen erweitern das Modell
Bagisto ist dafür ausgelegt, über Laravel-Packages, individuelle Produkttypen, Module, REST- oder GraphQL-APIs, Webhooks beziehungsweise Integrationscode und Headless-Storefronts erweitert zu werden. Dadurch können Daten entstehen, die nicht in den zentralen Product-, Customer- oder Order-Tabellen liegen.
Ein Package kann eigene Entitäten, Pivot-Beziehungen, Konfiguration, Status, Berechtigungen und externe Kennungen einführen. Ein Headless-Storefront kann zentrale Bagisto-Daten konsumieren, während Präsentationsinhalte oder Suchindizes an anderer Stelle liegen. ERP, PIM, WMS, CRM, Marketplace-Connector oder mobile Anwendung können Bagisto als einen Teilnehmer in einem größeren Datensystem behandeln.
| Dateneigentümer | Beispiele | Migrationsauswirkung |
|---|---|---|
| Bagisto-Core | Products, Categories, Customers, Orders, Attribute, Channels, Bestandsquellen | Nach nativer Entitäts- und Beziehungssemantik abbilden. |
| Installiertes Package | Marketplace-Verkäufer, B2B-Unternehmen, Buchungsressourcen, Abonnements, individuelle Produkttypen | Package-Schema prüfen und Links zu Core-Datensätzen erhalten. |
| Individuelles Laravel-Modul | Eigene Tabellen, Felder, Workflow-Datensätze oder Event-Historie | Für jede aktive Beziehung ein explizites Ziel oder eine Archiventscheidung definieren. |
| Headless-Präsentationsebene | Seitenkomposition, Suchindex, reine Frontend-Inhalte, gecachte Kennungen | Nicht annehmen, dass Storefront-Darstellung im Bagisto-Core gespeichert ist. |
| Externes System | ERP-Artikel-ID, CRM-Konto-ID, Warehouse-Code, Marketplace-Listing-ID | Kennungen bewahren, die den Zielshop wieder mit dem führenden System verbinden. |
Entscheidend ist die Eigentümerschaft. Ein Wert neben einem Product gehört nicht automatisch diesem Product. Er kann einem Package, einem externen System oder einer Präsentationsebene gehören. Der Migrationsumfang ist erst vollständig, wenn diese Beziehungen benannt und für operativ notwendige Datensätze ein Ziel definiert sind.
Entscheidungen zur Übertragung nach geschäftlicher Bedeutung
Die abschließende Entscheidung zum Datenmodell sollte jedes Quellmuster mit seinem Bagisto-Eigentümer und den Folgen einer falschen Zuordnung verbinden.
| Quellmuster | Richtige Übertragungsfrage | Folge einer falschen Annahme |
|---|---|---|
| Optionen mit Child-SKUs und Bestand | Handelt es sich um eine konfigurierbare Product-Beziehung? | Variantenidentität, Bestand oder Preis werden ungenau. |
| Wiederverwendete Spezifikationen einer Product-Klasse | Gehören sie in Attribute und eine Attributfamilie? | Filterung und Katalogverwaltung bleiben inkonsistent. |
| Getrennte regionale Stores | Sind dies Channels, Locales, Währungen oder unabhängige Installationen? | Products und Inhalte erscheinen im falschen Storefront-Kontext. |
| Lagerbezogene Mengen | Welche Bestandsquelle besitzt die jeweilige Menge? | Der Gesamtbestand kann stimmen, während die Standortverfügbarkeit falsch ist. |
| Wholesale- oder Unternehmens-Customers | Handelt es sich um Gruppe, B2B-Unternehmen, Unternehmensbenutzer oder externes Konto? | Preis-, Zugriffs- und Kontobeziehungen werden abgeflacht. |
| Verkäuferbezogene Products und Orders | Besitzt ein installiertes Marketplace-Package die Verkäuferbeziehung? | Verkäuferbesitz, Provisionen und Auszahlungskontext gehen verloren. |
| benutzerdefinierte Felder aus einem Package | Welche Package-Entität ist mit welchem Core-Datensatz verbunden? | Daten werden kopiert, ohne den Workflow zu erhalten, der sie verwendet. |
Eine Bagisto-Migration wird schlüssig, wenn Products, Attribute, Channels, Bestände, Customers, Orders, Inhalte, Packages und externe Kennungen als verbundene Strukturen übertragen werden. So bleibt mehr als Datenpräsenz erhalten: Die geschäftliche Bedeutung bleibt bestehen, mit der der Zielshop die migrierten Datensätze tatsächlich nutzen kann.
Fazit
Eine Migration zu Bagisto erfordert die Übertragung von Beziehungen über Katalog-, Storefront-, Bestands-, Customer-, Order-, Inhalts-, Erweiterungs- und Integrationsebenen hinweg. Produkttypen definieren verkaufbare Strukturen. Attributfamilien steuern Product-Informationen. Channels verbinden Katalog, Lokalisierung und Bestand. Customer-Gruppen sowie optionale B2B- oder Marketplace-Packages schaffen unterschiedliche Kontobeziehungen. Orders hängen von Positionen, Snapshots, Rechnungen, Sendungen, Erstattungen und Transaktionen ab. Packages und externe Systeme können Daten besitzen, die nicht zum Bagisto-Core gehören.
Die stärksten Umfangsentscheidungen identifizieren für jeden geschäftlich wichtigen Wert den Eigentümer und erhalten die Beziehungen zwischen Datensätzen. Wird Quelldaten nur anhand des Feldnamens zugeordnet, kann Bagistos Flexibilität semantische Verluste verdecken. Wird dagegen nach Zweck und Beziehung gemappt, erhält der Zielshop einen Katalog und eine Geschäftshistorie, die verständlich und nutzbar bleiben.
Häufige Fragen
Wie unterscheiden sich konfigurierbare Bagisto-Products von gewöhnlichen Product-Optionen?
Ein konfigurierbares Product verbindet ein Parent Product mit verkaufbaren Variationen, die aus ausgewählten Attributen entstehen. Die Variationen können eigene SKU, Preis, Menge, Bild oder Sichtbarkeit besitzen. Eine Textoption, die keine eigenständig verwaltete Variation identifiziert, sollte nicht automatisch in dieselbe Struktur überführt werden.
Warum sind Attributfamilien bei einer Bagisto-Migration wichtig?
Attributfamilien bestimmen, welche Attribute zu einer Product-Klasse gehören. Sie verhindern, dass jedes Product ein übergroßes universelles Feldset erhält, und helfen dabei, Bekleidungsspezifikationen, Gerätedaten, Download-Inhalte, Buchungsdetails und andere produktspezifische Informationen voneinander zu unterscheiden.
Kann ein Quellshop immer zu einem Bagisto-Channel werden?
Nein. Ein Quell-„Store“ kann Domain, Sprache, Währung, Marke, Region, Katalog oder unabhängige Geschäftseinheit darstellen. Das passende Bagisto-Modell kann je nach den Beziehungen, die getrennt bleiben müssen, einen Channel mit mehreren Locales, mehrere Channels oder getrennte Installationen verwenden.
Wie sollte Lagerbestand in Bagisto dargestellt werden?
Wenn der Standort relevant ist, sollte Bestand seine Bestandsquellen-Zuordnung behalten. Werden alle Mengen in einem einzigen Product-Gesamtbestand zusammengeführt, können Warehouse-, Abhol-, Lieferanten- oder Fulfillment-Kontext verloren gehen, obwohl die Summe weiterhin stimmt.
Sind Marketplace-Verkäufer und B2B-Unternehmen gewöhnliche Bagisto-Customers?
Nicht zwingend. Verkäufer- und Unternehmensbeziehungen können von installierten Marketplace- oder B2B-Packages verwaltet werden. Diese Strukturen können Organisationsbenutzer, Rollen, Kataloge, Provisionen, Auszahlungen, Kredit, Quotes oder Purchase Orders enthalten, die nicht in den Core-Customer passen.
Was sollte mit Daten aus Bagisto-Packages oder individuellen Modulen geschehen?
Identifizieren Sie das Package oder Modul, die erweiterten Core-Datensätze und den Geschäftsprozess, der die Daten nutzt. Aktive Beziehungen brauchen im Zielshop ein explizites Ziel und erhaltene Kennungen; veraltete Datensätze können archiviert oder ausgeschlossen werden, ohne fälschlich als native Product- oder Customer-Felder behandelt zu werden.