Bei der Bewertung von PrestaShop als mögliche Zielplattform zeigt das Datenmodell, wie Quelldaten, Beziehungen und geschäftliche Bedeutung in der Zielumgebung abgebildet werden müssen.
Bei der Bewertung von PrestaShop als mögliche Zielplattform ist die Datenmigration keine reine Übertragung gleichnamiger Felder. Sie übersetzt die Logik des Quellshops in ein Katalogmodell, das verkaufbare Varianten, beschreibende Eigenschaften, kundenseitige Personalisierung, Shop-Geltungsbereiche und modulverwaltetes Verhalten voneinander trennt. Vertraute Datensätze wie Produkte, Kategorien, Kunden, Bestellungen, Coupons, CMS Pages, Bilder und URLs erhalten in PrestaShop eine andere Bedeutung, sobald sie mit Kombinationen, Merkmalen, Kundengruppen, Multistore-Strukturen, Sprachen und Modulen verknüpft werden.
Der wichtigste Unterschied besteht darin, dass eine Quellplattform eine breite „Option“- oder Custom-Field-Ebene für mehrere Zwecke gleichzeitig nutzen kann. In PrestaShop muss ein Wert dagegen möglicherweise zu einem Attribut innerhalb einer Kombination, einem Merkmal des gesamten Produkts, einem vom Kunden ausgefüllten Anpassungsfeld, einer Produktbeziehung, einer Kategoriezuordnung, einer Kundengruppenbeziehung, einem shopspezifischen Wert oder einem modulgesteuerten Datensatz werden. Wer nur nach Feldnamen statt nach geschäftlicher Bedeutung zuordnet, kann einen technisch gefüllten, aber kaufmännisch widersprüchlichen Katalog erzeugen.
Die Kataloglogik von PrestaShop beginnt bei der Produktstruktur
PrestaShop-Produkte können Standardprodukte, Produkte mit Kombinationen, Packs oder virtuelle Produkte sein. Der Produktdatensatz ist außerdem mit Kategorien, Marken- und Lieferantenkontext, Bildern, Anhängen, verwandten Produkten, Merkmalen, Anpassungsfeldern, Preisen, Bestand, Sprachen und Shop-Geltungsbereichen verknüpft. Diese Beziehungen bestimmen, wie ein Produkt ausgewählt, dargestellt, verwaltet und verkauft wird.
| Bedeutung im Quellsystem | Frage für das PrestaShop-Ziel | Auswirkung auf die Beziehungen |
|---|---|---|
| Ein verkaufbarer Artikel ohne auswählbare Versionen | Bleibt er ein Standardprodukt? | Produktidentität, Referenz, Preis, Bestand, Bild, Steuer, Kategorie und URL verbleiben auf Produktebene. |
| Größe, Farbe, Kapazität, Oberfläche oder andere kaufbare Ausprägung | Sollen Attribute Kombinationen erzeugen? | Eine Kombination kann eigene Referenz, Preiswirkung, Menge, Bild und ausgewählte Werte besitzen. |
| Stabile Spezifikation wie Material oder Herkunftsland | Soll daraus ein Merkmal werden? | Der Wert beschreibt das gesamte Produkt, statt eine eigene kaufbare Variante zu erzeugen. |
| Vom Kunden eingegebener Text oder hochgeladene Personalisierung | Soll daraus ein Anpassungsfeld oder eine andere Zielstruktur werden? | Kundeneingaben bleiben von Attributen und beschreibenden Merkmalen getrennt. |
| Gruppe bestehender Produkte, die gemeinsam verkauft werden | Handelt es sich um einen Pack, eine Beziehung, eine Kategorie oder eine Merchandising-Verknüpfung? | Die Zielstruktur sollte Produktidentitäten und Gruppierungsabsicht bewahren, ohne Daten unnötig zu duplizieren. |
| Von einem Modul erzeugte Auswahl oder Datensatz | Welches Modul oder welcher Zielprozess ist dafür zuständig? | Kernfelder des Produkts dürfen aktives Erweiterungsverhalten nicht versehentlich übernehmen. |
Die richtige Zielrepräsentation richtet sich danach, was ein Wert tatsächlich bewirkt. Ein Wert mit der Bezeichnung „Farbe“ kann eine Kombination erzeugen, ein Produktmerkmal beschreiben, die Kategorisierung oder Filterung unterstützen oder lediglich durch ein Modul ausgegeben werden. Der Feldname allein reicht für diese Entscheidung nicht aus.
Kombinationen, Attribute, Merkmale und Anpassungen sind nicht austauschbar
PrestaShop-Kombinationen stehen für kaufbare Varianten eines Produkts. Sie werden aus Attributwerten gebildet und können eigene Referenzen, Preisaufschläge oder -abschläge, Mengen, Bildzuordnungen, Gewichtsänderungen, Verfügbarkeit und weitere variantenspezifische Daten tragen. Merkmale beschreiben dagegen Eigenschaften, die für das Produkt als Ganzes gelten. Anpassungsfelder sammeln Text oder Dateien, die ein Kunde selbst eingibt.
Diese Trennung sollte im migrierten Modell klar erkennbar bleiben:
| PrestaShop-Struktur | Kaufmännische Bedeutung | Typischer Fehler bei der Übertragung |
|---|---|---|
| Attributgruppe und Attributwert | Auswählbare Dimension wie Größe oder Farbe | Beschreibende Spezifikationen werden zu Auswahlfeldern, die Kunden unnötig auswählen müssen. |
| Kombination | Gültige kaufbare Kombination von Attributwerten | Echte Varianten werden zu einem Produkt zusammengefasst und verlieren Child-SKU, Preis, Bild oder Bestand. |
| Merkmal und Merkmalswert | Stabile Produkteigenschaft | Filter- oder Vergleichsinformationen werden zu freiem Text reduziert. |
| Anpassungsfeld | Vom Kunden eingegebener Text oder Datei | Personalisierung wird wie ein fester Attributwert oder eine Bestellnotiz behandelt. |
| Pack | Produktbeziehung, die bestehende Produkte gruppiert | Komponentendaten werden dupliziert oder ein Bundle fälschlich als Variante abgebildet. |
| Virtuelles Produkt | Nicht physisches Produkt mit eigener Auslieferungslogik | Eine Dateireferenz wird erhalten, aber Produkt- und Zugriffsbeziehungen gehen verloren. |
Eine Quellplattform kann Varianten als eigenständige Produkte speichern. In PrestaShop können sie als Kombinationen unter einem gemeinsamen Hauptprodukt sinnvoller abgebildet sein, wenn es tatsächlich nur verschiedene Versionen desselben Artikels sind. Umgekehrt sollten eigenständige Produkte nicht zu Kombinationen zusammengeführt werden, wenn sie eigene Merchandising-, Inhalts-, Lebenszyklus- oder Auswertungsidentitäten besitzen.
Auch die Bildung von Kombinationen hängt von einem konsistenten Attributvokabular ab. Uneinheitliche Werte wie „Large“, „L“ und „large“ sollten geprüft werden, bevor daraus getrennte Zielwerte entstehen. Eine Normalisierung darf jedoch keine Werte zusammenführen, wenn unterschiedliche SKUs, Preise, Bestände oder kundenseitige Bedeutungen dahinterstehen.
Kategorien, Marken, Lieferanten und Beziehungen steuern die Produktsuche
PrestaShop-Kategorien bilden hierarchische Katalogpfade und können Beschreibungen, Bilder, Metadaten, sprechende URLs, Produktzuordnungen und Shop-Kontext enthalten. Ein Produkt kann mehreren Kategorien zugeordnet sein, während eine davon als Hauptkategorie dient. Marken, Lieferanten, verwandte Produkte, Zubehör und Packs schaffen zusätzliche Such-, Merchandising- oder Betriebsbeziehungen.
Quellplattformen vermischen solche Rollen häufig. Eine Collection kann eine echte Produktfamilie, eine saisonale Kampagne, ein Markenarchiv, ein Filterergebnis, eine Navigationsabkürzung oder eine SEO-Landingpage sein. Wird jede Quellgruppierung pauschal als PrestaShop-Kategorie wiederhergestellt, können unnötige Strukturen und doppelte Bedeutungen übernommen werden.
| Struktur im Quellsystem | Mögliche Bedeutung in PrestaShop | Entscheidungssignal |
|---|---|---|
| Dauerhafte hierarchische Produktfamilie | Kategoriebaum | Kunden und Mitarbeitende nutzen die Hierarchie als stabilen Katalogpfad. |
| Marken- oder Herstellergruppierung | Markenbeziehung, Kategorie, Merkmal oder Inhaltsseite | Die Zielstruktur richtet sich nach Browsing, Vertrauen, Auswertung und Produkt-Governance. |
| Lieferantenreferenz | Lieferantenbeziehung oder externe Beschaffungskennung | Der Wert unterstützt Einkauf oder Administration statt Storefront-Branding. |
| Saisonale oder kampagnenbezogene Collection | Temporäre Kategorie, Merchandising-Regel oder Inhalts-Landingpage | Die Struktur muss nicht dauerhaft Bestandteil der Kataloghierarchie werden. |
| Verwandte Produkte oder Zubehör | Produktbeziehung | Die Beziehung unterstützt Cross-Selling, ohne die Produktidentität zu verändern. |
| Bundle bestehender Produkte | Pack oder andere klar definierte Bundle-Struktur | Komponenten bleiben identifizierbar und das Bundle wird nicht zu einer künstlichen Variante. |
Die Beziehung zur Hauptkategorie und zur sprechenden URL verdient besondere Aufmerksamkeit, weil der Kategorienkontext beeinflussen kann, wie Produktpfade erzeugt und interpretiert werden. Ein Produkt kann allen richtigen Kategorien zugeordnet sein und trotzdem einen unerwünschten primären Pfad erhalten, wenn die Hauptbeziehung falsch gesetzt ist.
Kundenidentität und Behandlung durch Kundengruppen müssen getrennt bleiben
Ein PrestaShop-Kundendatensatz enthält Identität, Kontaktdaten, Adressen, Kontostatus, Sprachkontext und Beziehungen zu Bestellungen. Kundengruppen können über Rabatte, Preisdarstellung, Sichtbarkeit oder andere konfigurierte Regeln beeinflussen, wie ein Käufer behandelt wird. Eine Gruppe ist deshalb mehr als nur eine Bezeichnung.
| Kundenmuster im Quellsystem | Frage für das Zielmodell | Ergebnis der Beziehung |
|---|---|---|
| Gewöhnliches Endkundenkonto | Welche Identität, Adresse, Sprache und Bestellverknüpfungen bleiben maßgeblich? | Die Kundenhistorie bleibt dem richtigen Konto zugeordnet. |
| Großhandels- oder Geschäftskunde | Welche Gruppe, Preis-, Steuer-, Sichtbarkeits- oder externe Kontobeziehung definiert die Behandlung? | Käuferidentität bleibt von den kaufmännischen Regeln getrennt. |
| Loyalty- oder Membership-Segment | Handelt es sich um eine Kern-Kundengruppe, einen Moduldatensatz, ein CRM-Segment oder nur eine historische Bezeichnung? | Im Ziel wird nur die Beziehung erhalten, die weiterhin genutzt werden soll. |
| Gastkäufer | Soll die Bestellung die Identität behalten, ohne ein reguläres Kundenkonto zu erzeugen? | Historische Bestellungen bleiben interpretierbar, ohne eine falsche Kontinuität des Kontos vorzutäuschen. |
| Doppelte Kundendatensätze | Welcher Datensatz besitzt E-Mail-Adresse, Adressen, Bestellungen und externe Kennungen? | Konsolidierung trennt Bestellungen nicht von der richtigen Kundenidentität. |
Eine Kundengruppe im Quellsystem kann Preise, Steuern, Katalogzugriff, Freigaben oder Kommunikation außerhalb des Kernshops beeinflusst haben. Nur den Gruppennamen zu migrieren erhält diese Wirkung nicht. Das Zielmodell muss festlegen, welches Verhalten durch PrestaShop-Konfiguration, ein Modul oder weiterhin durch ein externes CRM- oder ERP-System gesteuert wird.
Multistore ergänzt gemeinsame Datensätze um shopspezifische Zuständigkeit
Mit PrestaShop Multistore kann ein Back Office mehrere Shops oder Shop-Gruppen verwalten. Für eine Migration bedeutet das, dass Produkte, Kategorien, Kunden, Inhalte, Sprachen, Währungen, URLs und Modulverhalten gemeinsam genutzt, vererbt oder shopspezifisch sein können. Eine reine Datensatzanzahl zeigt nicht, ob diese Zuständigkeiten korrekt erhalten wurden.
| Multistore-Bereich | Zu klärende Zuständigkeit |
|---|---|
| Produkte und Kombinationen | Welche Shops erhalten Produkt, Variante, Sichtbarkeit, Preis und Bestandskontext? |
| Kategorien | Welcher Stammbaum und welche Shop-Zuordnung bestimmen die Position im Katalog? |
| Kunden und Gruppen | Welche Identitäten und kaufmännischen Behandlungen werden geteilt oder shopspezifisch verwaltet? |
| Sprachen und lokalisierte Felder | Welche übersetzten Namen, Beschreibungen, Slugs und Metadaten gehören zu welcher Sprache und welchem Shop? |
| CMS Pages und Inhalte | Welche Storefront, Sprache, Navigationsstruktur oder Domain besitzt den Inhalt? |
| URLs und Domains | Welcher Shop ersetzt welche wichtige Route aus dem Quellsystem? |
| Module | Welche Moduldaten oder Einstellungen gelten global, pro Shop-Gruppe oder pro einzelnem Shop? |
Wer alle Shop-Zuordnungen auf einen Standardshop reduziert, kann vollständige Datensätze anzeigen, aber Marken-, Regionen-, Sprach- oder B2B-/B2C-Grenzen verlieren. Das gegenteilige Problem entsteht, wenn jeder gemeinsame Datensatz pro Shop dupliziert wird: Dadurch wächst die Abweichung zwischen Shops unnötig und die spätere Katalogpflege wird schwieriger.
Bestellungen bewahren Transaktionsnachweise, nicht die zukünftige Shop-Konfiguration
PrestaShop-Bestellungen verbinden Kunden- oder Gastidentitäten mit Produktsnapshots, Kombinationen, Mengen, Preisen, Rabatten, Steuern, Versand, Zahlungsbezeichnungen, Adressen, Nachrichten, Statushistorien und Modulreferenzen. Historische Bestellungen sollten verständlich bleiben, auch wenn ein Ablauf aus dem Quellsystem in PrestaShop keine exakte Entsprechung besitzt.
| Bestellbeziehung | Bedeutung im Ziel-Datensatz |
|---|---|
| Produkt- und Kombinationsposition | Gekaufter Name, Referenz, ausgewählte Attribute, Menge und Preis zum Zeitpunkt des Kaufs. |
| Kunden- oder Gastidentität | Käuferkontext und Beziehung zu historischen Kontodaten. |
| Adressen | Rechnungs- und Lieferadressen als Transaktionssnapshot. |
| Rabatte und Gutscheine | Historische Auswirkung auf die Bestellung, nicht automatische Wiederherstellung zukünftiger Promotionsregeln. |
| Zahlungs- und Carrier-Bezeichnungen | Nachweis der ursprünglichen Transaktion, nicht Beleg dafür, dass entsprechende Zielmodule aktiv sind. |
| Status und Nachrichten | Historischer Ablauf- und Servicekontext, der möglicherweise semantisch zugeordnet werden muss. |
| Modul- oder externe Referenz | Systemübergreifende Kennung oder erweiterungseigener Kontext mit klar definiertem Zielzweck. |
Zahlungsmodule, Carrier, Steuerregeln, E-Mail-Templates oder individuelle Checkout-Anpassungen gehören zur aktiven Zielkonfiguration. Historische Bezeichnungen können erhalten werden, ohne vorzugeben, dass der zukünftige Ablauf bereits eingerichtet ist. Diese Grenze macht Bestellungen weiterhin für Kundenservice und Finanzen nutzbar und verhindert gleichzeitig, dass Transaktionshistorie mit Betriebssetup verwechselt wird.
Module, Overrides, Themes und benutzerdefinierte Daten brauchen eindeutige Eigentümer
Das Modul- und Override-Ökosystem von PrestaShop kann Produkte, Kombinationen, Kunden, Bestellungen, Checkout, Promotions, Reviews, Loyalty-Funktionen, Marketplace-Feeds, SEO, Versand, Zahlung, Auswertung und Administration erweitern. Ein Wert im Back Office oder in der Storefront kann daher aus einer Kerntabelle, einer Modultabelle, einem Override, Theme-Logik oder einem externen System stammen.
| Art der Abhängigkeit | Interpretation im Datenmodell |
|---|---|
| Moduleigener Datensatz | Übergeordnetes Produkt, Kundenkonto, Bestellung, Inhaltselement oder externen Datensatz sowie das konsumierende Zielmodul identifizieren. |
| Benutzerdefiniertes Feld eines Kerndatensatzes | Nur dann ein natives oder kontrolliertes Erweiterungsfeld verwenden, wenn der Zielverantwortliche feststeht. |
| Override oder individueller Code | Klären, ob Speicherung, Berechnung, Validierung oder Darstellung verändert wird, statt den Code als übertragbare Daten zu behandeln. |
| Theme-Feld | Dauerhafte Inhalte von quellenspezifischem Layout oder Template-Markup trennen. |
| Externe Kennung | ERP-, CRM-, PIM-, Buchhaltungs-, Marketplace- oder Auftragsabwicklung-Schlüssel innerhalb einer kontrollierten Integrationsbeziehung erhalten. |
| Zwischengespeicherte oder abgeleitete Ausgabe | Aus maßgeblichen Zieldaten neu erzeugen, statt veraltete technische Rückstände zu kopieren. |
Modulrückstände sollten nicht allein deshalb kopiert werden, weil sie vorhanden sind. Umgekehrt darf ein modulgesteuertes Feld, das Produktidentität, Kundenberechtigung, Bestellinterpretation oder Integrationskontinuität bestimmt, nicht als optionales Metadatum abgetan werden. Das Zielmodell muss den zukünftigen Verbraucher dieser Daten benennen.
Inhalte, Sprachen und URLs tragen Shop-Kontext
Produkt-, Kategorie-, CMS-Page- und andere Inhaltsfelder können in PrestaShop lokalisiert werden. Namen, Beschreibungen, Slugs, Metadaten und Bildtexte können sich nach Sprache und Shop unterscheiden. Eine Quellplattform kann dieselbe Anforderung stattdessen über getrennte Stores, duplizierte Datensätze, Übersetzungsplugins oder sprachspezifische URLs lösen.
Das Zielmodell sollte gemeinsame Identität und lokalisierte Darstellung voneinander trennen. Ein Produkt kann dieselbe Referenz und Beziehungsstruktur behalten, während Name, Beschreibung, Slug und Metadaten je Sprache variieren. Ein übersetzter Quelldatensatz sollte nicht zu einem separaten Produkt werden, wenn er in Wirklichkeit nur eine lokalisierte Darstellung desselben kaufmännischen Artikels ist.
Auch URLs benötigen einen eindeutigen Objektbezug. Eine Quellroute kann ein Produkt, eine Kategorie, eine Markenseite, eine CMS Page, einen Sprachpfad oder eine Shop-Domain repräsentieren. Die Zielroute sollte auf genau das PrestaShop-Objekt und den Shop-Kontext zeigen, die diese Funktion übernehmen. Eine sprechende URL ohne den korrekten Datensatz sowie die zugehörige Sprach- und Shop-Beziehung reicht nicht aus.
Zielzuständigkeit sollte vor der Feldzuordnung feststehen
Ein vollständiges PrestaShop-Zielmodell ordnet jeden wichtigen Quellwert einem der folgenden Ergebnisse zu:
- einer nativen Produkt-, Kombinations-, Attribut-, Merkmals-, Anpassungs-, Kategorie-, Kunden-, Bestell-, Inhalts- oder Shop-Beziehung;
- einem kontrollierten Modul- oder benutzerdefinierten Feld mit einem weiterhin zuständigen Zielsystem;
- einer Beziehung zu einem externen System, deren stabile Kennung nachvollziehbar bleiben muss;
- Zielkonfiguration oder Darstellung, die neu aufgebaut und nicht als Daten migriert werden sollte;
- historischen Rückständen, die archiviert oder ausgeschlossen werden sollten.
| Entscheidungsbereich | Starke Frage zur Zuständigkeit |
|---|---|
| Produktvariation | Welches Produkt und welche Attributkombination besitzen SKU, Preis, Menge, Bild und kaufbare Identität? |
| Produktinformation | Welche Werte sind Merkmale, Beschreibungen, Anhänge oder lokalisierte Inhalte und keine Kombinationen? |
| Produktsuche | Welche Kategorien, Marken, Lieferanten, Beziehungen und URLs erhalten die ursprüngliche Kundenabsicht? |
| Kundenbehandlung | Welche Gruppe oder externe Beziehung steuert Preise, Sichtbarkeit, Steuern oder Berechtigungen? |
| Multistore | Welcher Shop oder welche Shop-Gruppe ist für jede Zuordnung und jeden lokalisierten Wert zuständig? |
| Modul-/Custom-Daten | Welches Zielmodul, welches Team oder welches externe System nutzt den Datensatz künftig weiter? |
Diese Zuständigkeitslogik verhindert, dass PrestaShop lediglich zum Behälter für kopierte Quellbezeichnungen wird. Stattdessen kann der migrierte Katalog als kohärentes Geflecht aus Produkt-, Kunden-, Bestell-, Inhalts-, Shop- und Modulbeziehungen funktionieren.
Fazit
Die wichtigsten Unterschiede im PrestaShop-Datenmodell liegen in der Trennung zwischen Produkten und Kombinationen, Attributen und Merkmalen, festem Inhalt und kundenseitiger Personalisierung, Kundenidentität und Gruppenbehandlung, gemeinsamen Datensätzen und Multistore-Zuständigkeit, historischen Bestellungen und zukünftiger Konfiguration sowie Kerndatensätzen und moduleigenen Erweiterungen.
Eine zuverlässige Migration bewahrt diese Unterschiede, bevor einzelne Felder zugeordnet werden. Das Ergebnis ist nicht nur eine gefüllte Datenbank, sondern eine Zielstruktur, in der Produkte, Kundenkonten und Bestellungen über Shops, Sprachen, Module und verbundene Systeme hinweg eine eindeutige kaufmännische Bedeutung behalten.
Häufige Fragen
Warum unterscheiden sich PrestaShop-Kombinationen von allgemeinen Produktoptionen?
Kombinationen sind kaufbare Versionen eines Produkts, die aus Attributwerten entstehen. Sie können variantenspezifische Referenz, Preiswirkung, Menge, Bild, Gewicht und Verfügbarkeit besitzen. Ein beschreibendes Merkmal oder eine vom Kunden eingegebene Anpassung erfüllt dagegen eine andere Funktion.
Sind PrestaShop-Merkmale dasselbe wie Attribute?
Nein. Attribute bilden auswählbare Dimensionen für Kombinationen, während Merkmale stabile Produkteigenschaften beschreiben. Werden beide verwechselt, können Spezifikationen zu unnötigen Auswahloptionen werden oder echte Varianten auf Beschreibungstext reduziert werden.
Wie sollten Varianten aus dem Quellsystem behandelt werden, wenn sie dort als separate Produkte gespeichert sind?
Prüfen Sie, ob es tatsächlich verschiedene Versionen desselben Produkts oder eigenständige kaufmännische Artikel sind. Gemeinsame Identität, gemeinsame Inhalte, auswählbare Unterschiede sowie die Zuständigkeit für SKU, Bestand, Preis und Lebenszyklus helfen bei der Entscheidung, ob Kombinationen angemessen sind.
Warum reicht bei Kundengruppen eine reine Namenszuordnung nicht aus?
Eine Kundengruppe kann mit Rabatten, Preisdarstellung, Sichtbarkeit, Steuerbehandlung oder Modulverhalten verbunden sein. Die Beziehung zwischen Kunde und Gruppe sollte nur zusammen mit einer klaren Definition der kaufmännischen Behandlung erhalten werden, die im Zielshop weiter gelten soll.
Wie verändert Multistore die Datenzuordnung?
Multistore ergänzt Produkte, Kategorien, Kunden, Inhalte, Sprachen, URLs und Module um Shop- oder Shop-Gruppen-Zuständigkeit. Gemeinsame Datensätze sollten gemeinsam bleiben, wenn dies gewollt ist, während shopspezifische Zuordnungen nicht auf den Standardshop reduziert werden dürfen.
Wie sollten modulverwaltete Daten behandelt werden?
Jeder Moduldatensatz sollte auf sein übergeordnetes Objekt, seine geschäftliche Bedeutung und seinen zukünftigen Verbraucher im Zielsystem zurückgeführt werden. Dauerhafte Entitäten und Integrationsschlüssel können erhalten werden; aktives Verhalten sollte in der Zielumgebung neu eingerichtet werden. Zwischengespeicherte, abgeleitete oder veraltete Rückstände ohne zukünftigen Zweck sollten ausgeschlossen werden.