Bestell und Kaufhistorie migrieren

Jahre an Bestellungen lässt du nicht einfach zurück

Wenn ein Shop von einer gemieteten Plattform wegzieht, bekommen der Katalog und die Kundenliste die ganze Aufmerksamkeit, und die Bestellhistorie wird als etwas behandelt, das man später aufräumen kann. Das ist verkehrt herum gedacht. Den Katalog kannst du zur Not aus einem Lieferantenfeed neu aufbauen. Die Bestellhistorie kannst du aus gar nichts neu aufbauen, denn sie ist das Protokoll dessen, was tatsächlich passiert ist: wer was gekauft hat, zu welchem Preis, an welchem Tag, mit welcher Steuer, wohin geliefert, erstattet oder nicht. Verlierst du sie, hast du zugleich deinen gesetzlichen Nachweis und den wertvollsten Datensatz weggeworfen, den das Unternehmen besitzt.

Das hier ist der ehrliche Leitfaden dazu, was mit dieser Historie passiert, wenn ich einen Shop auf einen eigenen Store auf Solidus umziehe, dem quelloffenen Rails Framework für Onlinehandel, auf dem ich baue. Ich sage klar, was sauber mitkommt, was nur als schreibgeschützter Datensatz mitkommt und sonst nichts, und welche heiklen Ränder die Leute überraschen. Danach lege ich dar, dass die Historie keine Last ist, die du mitschleppst, sondern der Treibstoff für alles Nützliche, was du im neuen Store tun kannst: Bedarfsprognose, Nachbestellung, Kohortenanalyse und Warenkorbanalyse. Dieser Beitrag ist eine Speiche einer größeren Serie, also beginne beim Elternartikel, was sich beim Onlineshop Umzug überträgt und was nicht, und lies ihn zusammen mit dem Schwesterstück zu Analyse und Verlaufsdaten für Prognosen.

Warum du sie behältst, und warum ein Verlust keine Option ist

Es gibt fünf Gründe, warum ein etablierter Shop seine Bestellhistorie mitnehmen muss, und sie bauen aufeinander auf.

Der erste ist der Kundendienst. Eine Kundin schreibt wegen eines Pakets, das nie ankam, oder wegen eines Garantiefalls auf einen Sessel, der vor zwei Jahren gekauft wurde. Deine Leute müssen diese Bestellung öffnen, die Positionen sehen, den bezahlten Preis, die Lieferadresse und die Sendungsverfolgung, und in einer Antwort antworten statt in zehn.

Der zweite ist das Gesetz. Die Finanzbehörden setzen Mindestfristen für die Aufbewahrung von Geschäfts und Steuerunterlagen, und eine Bestellung ist eine Steuerunterlage. In Österreich sind Bücher, Aufzeichnungen und die zugehörigen Belege sieben Jahre aufzubewahren, gerechnet ab dem Ende des Kalenderjahres, und länger, wenn sie für ein offenes Abgabenverfahren von Bedeutung sind.¹ Die Fristen unterscheiden sich von Land zu Land, und ein Shop, der grenzüberschreitend verkauft, haftet mehreren davon gleichzeitig. So sieht das Bild für die Rechtsordnungen aus, die diese Serie abdeckt.

Wo du Steuerunterlagen aufbewahrst	Mindestfrist	Quelle
Österreich (Bücher, Aufzeichnungen, Belege)	7 Jahre ab Ende des Kalenderjahres	Bundesabgabenordnung §132 ¹
Deutschland (Bücher, Jahresabschlüsse)	10 Jahre	Abgabenordnung §147 ²
Deutschland (Buchungsbelege, Rechnungen)	8 Jahre, seit 2025 von 10 gesenkt	Abgabenordnung §147 ²
Vereinigtes Königreich (Buchführung einer Limited)	6 Jahre ab Ende des letzten Geschäftsjahres	HMRC ³
Irland (Umsatzsteuer und Geschäftsunterlagen)	6 Jahre, außer Revenue genehmigt kürzer	Revenue ⁴

Der dritte Grund sind Garantie und Rückgaben. Eine Gewährleistung läuft ab dem Verkaufstag, und eine Rückgabe braucht die Originalbestellung, um zu prüfen, was gekauft und was bezahlt wurde. Der vierte ist Geld: Wiederkaufrate, durchschnittlicher Bestellwert und Kundenwert über die Lebensdauer liest du direkt aus der Bestellhistorie, und daran erkennst du, welche Kunden und welche Produkte es wert sind, gehalten zu werden. Der fünfte ist die Prognose, auf die ich ausführlich zurückkomme, denn dort zahlt sich die Historie aus.

Beachte: Die ersten vier sind Gründe, warum du die Daten nicht verlieren darfst. Der fünfte ist ein Grund, warum du froh sein solltest, sie zu besitzen.

Was tatsächlich mitkommt

Eine Bestellung ist nicht eine einzige Sache. Sie ist ein kleines Bündel aus Datensätzen, und jeder Teil muss mitkommen, damit die Bestellung etwas wert ist. Das Folgende kommt sauber mit, mit Zuordnungsarbeit.

Die Bestellung selbst: ihre Nummer, ihr Datum samt Uhrzeit, ihr Status (aufgegeben, bezahlt, versandt, abgeschlossen, storniert) und ihre Währung.
Die Positionen: für jede das Produkt und die Variante, die Menge und der Preis zum Zeitpunkt des Verkaufs, der fast nie der heutige Preis ist.
Das Geld: die berechnete Steuer, ein etwaiger Rabatt oder eine Aktion, die Versandkosten und die Bestellsumme, genau so, wie sie der Kundin verrechnet wurden.
Die Menschen und Orte: die Verknüpfung zum Kundenkonto sowie die Rechnungs und Lieferadresse, wie sie an dem Tag erfasst waren, nicht wie das Adressbuch der Kundin heute aussieht.
Die Zustellung: welche Artikel wann über welchen Zusteller versandt wurden, samt Sendungsnummer.
Die Folgen: Rückerstattungen, Teilrückerstattungen und Retouren zur Bestellung, mit Betrag und Datum.

Das aus der alten Plattform herauszubekommen, ist meist eine Frage von Bericht oder Schnittstelle. Die meisten Plattformen geben dir einen vollständigen Bestellexport als Tabelle: Shopify etwa exportiert eine CSV Datei mit Positionen, Zahlungs und Versandstatus, Summen, Rabatten, Versandart, Datumsangaben und Adressen, bei kleinen Mengen als Download und ab fünfzig Bestellungen oder bei jedem Export nach Datum per Mail.⁵ Für einen sauberen, wiederholbaren Zug bevorzuge ich die Schnittstelle der Plattform, wo es eine gibt. WooCommerce stellt jede Bestellung über seine REST Schnittstelle am Endpunkt für Bestellungen bereit, sodass ein Skript den ganzen Bestand durchblättern kann, Felder intakt, und sie direkt in die Form schreibt, die der neue Store braucht.⁶ Ein Bericht reicht für einen einmaligen Zug. Eine Schnittstelle ist besser, wenn du den Export mehrmals laufen lässt, und das tust du, wie du gleich siehst, immer.

Preise und Steuern bleiben, wie sie waren

Hier ist die Regel, die entscheidet, wie importierte Bestellungen gespeichert werden, und es ist der Teil, den die meisten Umzugspläne falsch machen. Eine Bestellung hält fest, was am Tag der Aufgabe wahr war. Der Preis war der Preis von damals. Die Steuer war der Satz von damals. Der Rabatt war die Aktion dieser Woche. Nichts davon darf gegen heutige Preise, heutige Steuersätze oder heutige Aktionen neu berechnet werden, denn dann würde die Bestellung nicht mehr zur Rechnung passen, die die Kundin hält, nicht zur Zahlung, die kassiert wurde, und nicht zur Zahl, die dein Steuerberater längst gemeldet hat.

Steuersätze sind das klarste Beispiel, denn sie ändern sich und die Änderungen sind datiert. Österreich senkte in der Coronakrise den Umsatzsteuersatz für Gastronomie, Beherbergung und Kultur befristet auf 5 %, gültig vom 1. Juli 2020 bis 31. Dezember 2020.⁷ Eine Bestellung aus diesem Fenster trägt für immer 5 %. Würde ein Umzug ihre Steuer auf den heutigen Satz neu rechnen, wäre die Bestellung falsch, und jede Summe, die auf ihr aufbaut, wäre es auch. Dasselbe gilt für einen Shop, der eine Aktion fuhr, einen Gutschein einlöste oder in einer zweiten Währung verkaufte: Die erfassten Zahlen sind die historische Wahrheit und müssen als feste Werte importiert werden, nicht als Formeln, die der neue Store auswertet.

Darum werden importierte Bestellungen als historische Datensätze gespeichert und nicht zurück durch die Maschinerie geschickt, die einen neuen Warenkorb bepreist. Das führt direkt zum nächsten Punkt.

Importierte Bestellungen sind von Natur aus schreibgeschützt

Auf einer modernen Handelsplattform ist eine laufende Bestellung keine statische Zeile. Sie ist eine kleine Zustandsmaschine: aus einem Warenkorb wird eine Bestellung, die Bestellung durchläuft Adresse, Lieferung, Zahlung und Bestätigung, und erst dann ist sie abgeschlossen. Solidus arbeitet genau so, eine Bestellung rückt durch diese Zustände vor und trägt einen Abschlusszeitstempel, sobald sie fertig ist.⁸ Jeder Übergang löst die richtige Steuerberechnung, die richtige Aktionslogik und die richtige Lagerbewegung für einen heute laufenden Shop aus.

Eine Bestellung aus deinem alten Shop hat das alles schon vor Jahren durchlaufen, in einem anderen System, unter anderen Preisen und Regeln. Du kannst sie nicht zurück durch die laufende Engine des neuen Stores schicken, denn die Engine würde versuchen, sie zu bepreisen, zu besteuern und zu bewerben, als geschähe sie jetzt, und käme zu einer anderen, falschen Antwort. Also kommen importierte Bestellungen als abgeschlossene historische Datensätze herein: getreue Kopien, verriegelt, da zum Nachschlagen und Auswerten, nie zum erneuten Verarbeiten. Neue Bestellungen, aufgegeben nach der Umstellung, nutzen die laufende Engine wie gewohnt.

In der Praxis hält der neue Store damit zwei Arten von Bestellung, die in einer Liste ähnlich aussehen, sich aber unterschiedlich verhalten. Eine historische Bestellung kannst du lesen, durchsuchen, auswerten und der Kundin in ihrem Konto zeigen. Eine laufende Bestellung kannst du zusätzlich bearbeiten: erstatten, neu versenden, ändern. Importierte Bestellungen wieder voll laufend machen zu wollen ist ein verlockender Fehler, und es ist der falsche. Das ehrliche Design belässt sie als den Datensatz, der sie sind.

Die heiklen Ränder

Wäre der Umzug der Bestellhistorie nur ein Kopieren sauberer, abgeschlossener Verkäufe, wäre es ein Wochenende Arbeit. Ist es nicht, wegen der Ränder. Das sind die Fälle, die du beim Namen einplanst.

Teilrückerstattungen und Teilretouren. Eine Bestellung über vier Artikel, bei der einer zurückkam und erstattet wurde, ist weder voll erstattet noch unberührt. Der Import muss den exakten erstatteten Betrag und die genauen Positionen tragen, auf die er sich bezog, sonst stimmt dein Umsatz je Monat nicht.

Umtausch und Ersatz. Ein zurückgegebener Artikel, der gegen einen anderen getauscht wird, lebt mal als Erstattung plus neue Bestellung, mal als Änderung der Originalbestellung. Entscheide dich und wende es einheitlich an, sonst wird dasselbe Ereignis im einen Shop doppelt gezählt und im anderen gar nicht.

Teillieferungen. Eine Bestellung, in zwei Paketen an zwei Tagen zugestellt, vielleicht von zwei Standorten, hat mehr als einen Zustellungssatz. Plättest du sie zu einem einzigen Versanddatum, verlierst du die Wahrheit über Lieferzeiten, also genau die Daten, die du später für eine Auswertung der Servicequalität willst.

Bestellungen in mehreren Währungen. Ein Shop, der in Euro und Pfund verkaufte, erfasste jede Bestellung in der Währung, in der die Kundin zahlte. Diese Zahlen bleiben in ihrer Ursprungswährung, mit festgehaltener Umrechnungsbasis, und werden nur je für die Auswertung umgerechnet, nie umgeschrieben.

Steuer, die sich über die Jahre änderte. Das Beispiel oben ist keine Randnotiz. Ein Shop mit einem Jahrzehnt Historie hat Bestellungen zu mehr als einem Satz, und der Import muss den Satz bewahren, den jede Bestellung tatsächlich trug.

Gutscheine und Guthaben. Eine alte Bestellung, teils mit Gutschein oder Guthaben bezahlt, braucht das Zahlungsmittel so erfasst, wie es war, sonst passt das tatsächlich kassierte Geld nicht zur Bank.

Bestellungen im Flug zur Umstellung. Der härteste Rand ist die Bestellung, die am Umstellungstag aufgegeben, aber noch nicht versandt oder versandt, aber noch nicht zugestellt ist. Die ehrliche Antwort ist, diese nicht als laufende Bestellungen in den neuen Store zu holen. Lass das alte System sie zu Ende bringen: Es hält bereits die Zahlung, die Lagerreservierung und die Erwartung der Kundin. Starte den neuen Store sauber, mit einem bekannten Stichtag, und importiere diese letzten Bestellungen erst als Historie, sobald sie im alten System abgeschlossen sind. Eine saubere Linie schlägt eine clevere.

Was die Historie wert ist

Jetzt der Teil, der aus einer Last ein Gut macht. Alles oben dreht sich darum, das Protokoll getreu mitzutragen. Hier geht es darum, was dir das Protokoll ermöglicht, sobald es dir gehört, in deiner eigenen Datenbank, abfragbar, statt eingesperrt in einer Plattform, die es dir über einen Berichtsschirm zurückvermietet. Dass die Daten dir gehören, ist der ganze Punkt, und das ist das Thema von wem deine Geschäftsdaten eigentlich gehören.

Die Bestellpositionshistorie ist der Mindestrohstoff für die Bedarfsprognose. Eine Prognose muss die Verkäufe jedes Produkts über die Zeit sehen, um drei Dinge aufzunehmen: den Trend (driftet die Nachfrage nach oben oder unten), die Saisonalität (die Weihnachtsspitze, das Tief im Jänner, der Sommerdurchhänger) und die Autokorrelation (die Verkäufe dieser Woche tragen Information über die nächste). Das sind die üblichen Komponenten, in die man eine Zeitreihe zerlegt, und Saisonalität wie kurzfristige Abhängigkeit liest man direkt aus dem Muster vergangener Verkäufe.⁹¹⁰ Die Mechanik gehe ich in Nachfrageprognose, Autokorrelation und Saisonalität durch, und die ehrliche Frage, wie viel du brauchst, in wie viele Daten du wirklich brauchst. Kurz gesagt: Eine Prognose ist nur so gut wie die saubere Historie dahinter, und zwei oder drei Jahre Bestellungen, abgestimmt und korrekt, trennen eine brauchbare Prognose von einem Rätselraten. Die breitere Begründung für Prognosen auf einem Shop, der dir gehört, steht in KI gestützte Bedarfsprognose für Onlinehandel.

Dieselbe Historie füttert drei weitere Dinge, die ein gemieteter Berichtsschirm selten hergibt. Sicherheitsbestand und Nachbestellpunkte, damit du genug hältst, um die Nachfrage über die Wiederbeschaffungslücke zu decken, ohne im Lager zu ersaufen, was die Schwankung der vergangenen Nachfrage braucht, nicht nur ihren Durchschnitt. Kohorten und Wiederkaufanalyse, damit du weißt, ob Kunden, die in einem bestimmten Monat kamen, wiederkommen, und was ein Kunde über die Zeit wert ist. Und die Warenkorbanalyse, welche Paare verlässlich zusammen verkauft werden, damit der Shop das richtige Begleitprodukt vorschlagen kann, ein Thema, das ich in Cross Selling und Upselling im Checkout behandle. Nichts davon ist möglich, wenn die Historie zurückblieb, und alles davon ist Routine, sobald die Historie in einer Datenbank liegt, die du kontrollierst.

Die ehrliche Einordnung lautet also: Du behältst die Bestellhistorie, weil Gesetz und Kunden es verlangen, und du bist froh, sie behalten zu haben, weil sie der Eingang zu jeder Auswertung ist, die den neuen Shop klüger macht als den alten.

Der praktische Weg

Die Historie zu bewegen ist eine Abfolge, und die Reihenfolge zählt.

Zuerst: extrahieren. Zieh die volle Bestellhistorie aus der alten Plattform, über die Schnittstelle, wo es eine gibt, über einen Bericht, wo nicht, mit jedem oben genannten Feld. Rechne damit, den Zug mehr als einmal zu fahren, denn der erste Durchgang legt immer ein Feld offen, das du übersehen hast.

Zweitens: zuordnen. Die Produktkennungen, Statusnamen, Steuerbezeichnungen und Zahlungsarten der alten Plattform müssen auf die des neuen Stores abgebildet werden. Eine alte Bestellung zeigt auf ein Produkt, das eine neue Kennung haben kann oder nicht mehr existiert und einen Platzhalter braucht, damit die Position noch lesbar ist. Das ist sorgfältige, unglamouröse Arbeit, und dort gehen die Tage hin.

Drittens: als historische Bestellungen importieren. Lade die zugeordneten Bestellungen als abgeschlossene Datensätze in den neuen Store, nicht über die laufende Kasse, und bewahre jede Zahl so, wie sie erfasst wurde.

Viertens: abstimmen. Das ist der Schritt, den die Leute überspringen und bereuen. Zähle die Bestellungen je Monat und summiere den Umsatz je Monat im alten System, dann im neuen, und bring beide zur exakten Übereinstimmung. Nicht ungefähr. Eine einzige falsch gezählte Bestellung ist ein Faden, an dem du ziehst, bis der ganze Monat sich auftrennt. Die monatliche Bestellanzahl und der monatliche Umsatz, alt gegen neu, auf den Cent, sind der Abnahmetest.

Fünftens: eine Stichprobe von Hand prüfen. Nimm ein Dutzend Bestellungen über die Spanne, darunter eine Teilrückerstattung, eine Bestellung über mehrere Positionen, eine rabattierte und eine aus der Zeit vor einer Steueränderung, und prüfe jedes Feld gegen den Bildschirm des alten Shops. Automatische Summen können stimmen, während einzelne Felder still falsch sind, und nur ein menschliches Auge fängt das.

Ein durchgerechnetes Beispiel

Alles Folgende ist erfunden, um die Schritte zu zeigen. Kranz und Berger ist ein Shop für Wohnaccessoires in Linz, der unter kranzundberger.example handelt und von Petra geführt wird. Er ist seit fünf Jahren auf WooCommerce und ist ihm entwachsen: Die Auswertung beantwortet ihre Fragen nicht, und die Kasse kann nicht, was sie will. Sie zieht auf einen eigenen Solidus Store um, der ihr gehört. Mitzunehmen sind rund 120.000 Bestellungen über diese fünf Jahre, etwas über 11,2 Millionen Euro Umsatz.

Ich ziehe die Bestellungen über die REST Schnittstelle von WooCommerce statt über eine Tabelle, denn 120.000 Bestellungen brauchen mehrere Durchgänge, und ein Skript ist wiederholbar, wo ein händischer Export es nicht ist.⁶ Der erste Durchgang bringt die üblichen Probleme hoch: eine Reihe Bestellungen aus dem Steuerfenster 2020 mit 5 % neben jüngeren mit 20 %, die der Import auseinanderhalten muss;⁷ rund 900 Bestellungen, teils mit Guthaben bezahlt; eine Phase vor zwei Wintern, in der eine Bundle Aktion dazu führt, dass die Positionspreise nur dann zur Bestellsumme passen, wenn die Rabattzeile mitgenommen wird; und etwa 300 Bestellungen, die auf zwei Lieferungen aufgeteilt sind.

Die Zuordnung frisst den Großteil einer Woche. Petras Produktcodes änderten sich einmal in den fünf Jahren, also zeigen manche alten Positionen auf Codes, die übersetzt werden müssen, und etwa vierzig eingestellte Produkte werden zu Platzhaltern, die weiterhin den Namen und den Preis zeigen, den die Kundin zahlte. Dann lädt der Import alles als historische, abgeschlossene Bestellungen in Solidus.

Die Abstimmung ist, wo das Projekt wirklich geprüft wird. Der erste Lauf liegt über sechzig Monate um 3.214 Euro daneben. Die Suche findet zwei Ursachen: Die Guthabenzahlungen wurden fallen gelassen, und eine Bestellung am Schalttag war durch einen Datumsfilter gefallen. Behoben, stimmt der zweite Lauf: jede Monatsbestellanzahl identisch, jeder Monatsumsatz auf den Cent identisch, altes System gegen neues. Dieser Abstimmungsbericht, abgezeichnet, ist der Moment, in dem die Historie vertrauenswürdig ist.

Der Lohn kommt vierzehn Tage später. Zum ersten Mal kann Petra eine saubere Saisonalitätsansicht über alle fünf Jahre in ihrer eigenen Datenbank fahren: eine verlässliche Spitze im November und Dezember, ein tiefes Tief im Jänner, ein kleinerer Anstieg im Spätsommer, den sie immer halb geahnt, aber nie gemessen hatte. Auf WooCommerce war diese Abfrage langsam, teilweise und hinter dem Berichtsschirm verriegelt. Auf einem Store, der ihr gehört, ist sie eine Frage, die sie jederzeit stellen kann, und die Antwort ist der Ausgangspunkt für den Einkauf des nächsten Jahres. Die Historie, die sie fast zurückgelassen hätte, war am Ende das Nützlichste, was sie mitnahm.

Worauf es hinausläuft

Die Bestellhistorie kommt mit, aber sie kommt als getreuer, schreibgeschützter Datensatz mit, auf den Cent abgestimmt, nicht als laufende Bestellungen, die du erneut fahren kannst. Die heiklen Ränder, Teilrückerstattungen, Teillieferungen, geänderte Steuersätze, Guthaben und die Bestellungen im Flug am Umstellungstag, werden je mit Absicht behandelt, nicht überspielt, und die bei der Umstellung noch offenen Bestellungen werden im alten System zu Ende gebracht, damit das neue sauber startet. Machst du das ordentlich, hast du das Gesetz erfüllt und deine Kunden weiter bedient. Der eigentliche Lohn kommt danach: Die Historie, nun in einem Store, der dir gehört und den du abfragen kannst, ist der Rohstoff für Prognose, Nachbestellung und die Kundenauswertung, die die alte Plattform dir nie erlaubte. Das ist der Unterschied zwischen deine Vergangenheit mieten und sie besitzen.

Wenn du einen Umzug abwägst und dir Sorgen um Jahre an Bestellungen machst, bring das in einen kostenlosen Workshop, und ich bilde genau ab, was deine Historie enthält, was sauber mitkommt, was eine Entscheidung braucht und was sie wert ist, sobald sie dir gehört. Die ersten zwei Wochen Arbeit gehen auf mich, und wenn die Abstimmung schwer aussieht, sage ich es dir, bevor wir anfangen.

Bundesabgabenordnung §132, Aufbewahrung von Büchern, Aufzeichnungen und Belegen (sieben Jahre), jusline.at, 2026, https://www.jusline.at/gesetz/bao/paragraf/132 ↩ ↩²
Abgabenordnung §147, Ordnungsvorschriften für die Aufbewahrung von Unterlagen (zehn Jahre für Bücher und Jahresabschlüsse, acht Jahre für Buchungsbelege), Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/ao_1977/__147.html ↩ ↩²
HM Revenue and Customs, Running a limited company: company and accounting records (Aufbewahrung sechs Jahre ab Ende des letzten Geschäftsjahres), GOV.UK, 2026, https://www.gov.uk/running-a-limited-company/company-and-accounting-records ↩
Irish Revenue, How long do you keep records for? (sechs Jahre, außer Revenue genehmigt schriftlich eine kürzere Frist), revenue.ie, 2026, https://revenue.ie/en/vat/vat-records-invoices-credit-notes/vat-records-to-be-kept/how-long-keep-records.aspx ↩
Shopify, Exporting orders to a CSV file (Inhalt des Bestellexports und die Mengenregeln), Shopify Help Center, 2026, https://help.shopify.com/en/manual/orders/export-orders ↩
WooCommerce, REST API Documentation: Orders (Bestellungen programmatisch auflisten, abrufen und durchblättern), woocommerce.github.io, 2026, https://woocommerce.github.io/woocommerce-rest-api-docs/#orders ↩ ↩²
1. COVID-19-Gesetz, BGBl. I Nr. 48/2020 (befristeter ermäßigter Umsatzsteuersatz von 5 % für Gastronomie, Beherbergung und Kultur, 1. Juli bis 31. Dezember 2020), Rechtsinformationssystem des Bundes, 2020, https://www.ris.bka.gv.at/eli/bgbl/I/2020/48
↩ ↩²
Solidus, core/app/models/spree/order.rb (die Zustandsmaschine der Bestellung: cart, address, delivery, payment, confirm, complete, mit Abschlusszeitstempel), solidusio/solidus auf GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/order.rb ↩
Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Kapitel zur Zeitreihenzerlegung (Trend, saisonale und Restkomponente), OTexts, 2021, https://otexts.com/fpp3/decomposition.html ↩
Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice, 3. Auflage, Autokorrelation (Saisonalität und kurzfristige Abhängigkeit in der Autokorrelationsfunktion), OTexts, 2021, https://otexts.com/fpp3/acf.html ↩