Drei Dinge, die WooCommerce mit Ihren Kostendaten tut und von denen Ihnen niemand erzählt

WooCommerce 10.3 hat die Kosten der verkauften Waren in den Kern gebracht und damit etwas, das die Plattform nie hatte: einen Wareneinsatz, der in der Bestellposition im Moment des Verkaufs erfasst wird. Genau das ist der wertvolle Teil. Eine Bestellung vom März sagt weiterhin, was die Ware im März gekostet hat, auch nach zwei Preiserhöhungen des Lieferanten.

Drei Verhaltensweisen rund um dieses Feld überraschen alle, die darauf aufbauen. Fehler sind sie nicht in dem Sinn, dass Code etwas täte, was sein Autor nicht wollte; jede hat einen vertretbaren Grund. Es sind Überraschungen, und eine Überraschung, von der man aus der E-Mail eines Kunden erfährt, ist teurer als eine, über die man vorher gelesen hat.

Alles Folgende wurde im Quellcode von WooCommerce, Version 11.0.1, im September 2026 nachgeprüft. Funktions- und Dateinamen stehen dabei, damit Sie nachprüfen können, statt uns beim Wort zu nehmen.

Eine Codezeile erklärt alle drei

Beim Speichern der Daten einer Bestellposition läuft der Wareneinsatz durch save_cogs_data() in abstract-wc-order-item-type-data-store.php:

$cogs_value = (float) $cogs_value;
if ( 0.0 === $cogs_value ) {
    $this->order_item_data_store->delete_metadata( $item->get_id(), '_cogs_value', '' );
} else {
    $this->order_item_data_store->update_metadata( $item->get_id(), '_cogs_value', $cogs_value );
}

Lesen Sie das noch einmal mit einem Gedanken im Kopf: Null ist hier kein Wert, Null bedeutet Löschen.

Merken Sie sich das. Die beiden anderen Fallen sind dieselbe Zeile, auf zwei verschiedenen Wegen erreicht: einmal über eine Erstattung, einmal über ein Kontrollkästchen in den Einstellungen. Wer diesen Zweig versteht, kann beide vorhersagen.

Falle 1: Ein Wareneinsatz von null und gar kein Wareneinsatz sind dasselbe

Die direkte Folge. Ein Produkt, das Sie wirklich nichts kostet (ein Gratismuster, eine Werbetasse, ein herunterladbares Extra), wird in der Bestellposition genauso gespeichert wie ein Produkt, für das nie jemand Kosten eingetragen hat: als gar nichts.

Es gibt kein Kennzeichen, keine Null, keine Markierung, die sagt, welcher der beiden Fälle es war. Und ein Produkt ohne eingetragenen Wareneinsatz liefert aus get_cogs_total_value() den Wert 0, beide Wege enden also beim selben Löschen.

Das hat eine gute Seite. Weil das Fehlen wirklich wir wissen es nicht bedeutet, kann ein Bericht ehrlich sagen, für welchen Anteil des Umsatzes ein Wareneinsatz vorliegt, statt Unbekanntes stillschweigend als kostenlos zu behandeln. Die Abdeckung ist eine echte Zahl, keine Schätzung.

Die Kehrseite ist ein dauerhaftes Ärgernis: Ihre echten Gratisartikel stehen für immer auf der Liste fehlender Kosten, und kein Plugin kann sie herunternehmen, weil die Information, die sie unterscheiden würde, nie aufgeschrieben wurde.

Eine Asymmetrie sollten Sie kennen, denn sie entscheidet, wie eine solche Liste gebaut werden muss. Beim Produkt wird ein Wareneinsatz von null sehr wohl gespeichert: Der Datenspeicher für Produkte löscht nur leere Zeichenketten und leere Arrays, keine Nullen. Auf Produktebene lassen sich null und fehlend also unterscheiden, auf Ebene der Bestellposition nicht. Eine Liste „Produkte ohne Wareneinsatz“ muss deshalb aus dem Produkt gelesen werden, die Abdeckung dagegen aus den Bestellpositionen. Zwei verschiedene Datenquellen, aus gutem Grund. Mehr zu null und fehlend.

Falle 2: Eine Erstattung schreibt den erfassten Wareneinsatz der ganzen Bestellung neu

Diese Falle ändert Zahlen, die Sie schon in Berichten verwendet haben, und sie ist der Grund, diese Seite zu lesen, bevor Sie eine Auswertung auf diesen Daten aufbauen.

Am Ende von wc_create_refund() in wc-order-functions.php:

if ( ...->feature_is_enabled() && $order->has_cogs() ) {
    $order->calculate_cogs_total_value();   // <- die ÜBERGEORDNETE Bestellung
}
$order->save();

Dieser Aufruf beschränkt sich nicht auf die erstatteten Positionen. calculate_cogs_total_value_core() in abstract-wc-order.php geht jede Position der übergeordneten Bestellung durch und ruft $item->calculate_cogs_value() auf, das den Wareneinsatz aus dem Produkt so liest, wie er heute ist. Dann schreibt save() alle geladenen Positionen zurück.

Wer also einen Artikel aus einer Bestellung mit zwölf Positionen erstattet, lässt den erfassten Wareneinsatz aller zwölf aus den heutigen Produktkosten neu berechnen. Hat sich ein Einkaufspreis inzwischen geändert, ändert sich die Historie mit. Die Zahlen für März zeigen nicht mehr, was die Ware im März gekostet hat.

Kombinieren Sie das jetzt mit Falle 1. Wurde der Wareneinsatz des Produkts irgendwann geleert, ergibt die Neuberechnung 0, und 0 löscht. Die Kostenhistorie der Bestellung wird dann nicht nur neu dargestellt, sie ist weg, und es gibt nichts, woraus man sie wiederherstellen könnte.

Eine Erstattung ist kein Sonderfall. Sie ist Alltag. Wie das in einem Bericht aussieht.

Falle 3: Das Ausschalten der Funktion kann beim nächsten Speichern Daten zerstören

Gemessen unter WooCommerce 10.3.0: Das Entfernen des Häkchens bei den Kosten der verkauften Waren löscht für sich allein nichts. Das muss man klar sagen, denn es ist das Gegenteil dessen, was viele befürchten.

Das Risiko liegt in dem, was danach passiert. Bei ausgeschalteter Funktion liefern get_cogs_total_value() und calculate_cogs_value() die Werte 0 und false. Und Null löscht, siehe Falle 1. Jeder spätere Schreibvorgang, der die Positionen einer Bestellung berührt (eine alte Bestellung im Administrationsbereich bearbeiten, eine Erstattung dafür auslösen, eine Aktualisierung über die REST-API), führt also die Neuberechnung aus, bekommt null und löscht den gespeicherten Wareneinsatz dieser Positionen.

Die Reihenfolge dieser beiden Tatsachen zählt. „Ausschalten ist sicher“ und „eine Bestellung danach anzufassen ist es nicht“ stimmen beide, und nützlich sind sie nur zusammen. Der ganze Ablauf.

Was für diese Entscheidungen spricht

Keine der drei Entscheidungen ist nachlässig.

Nullen zu löschen verhindert, dass sich die Meta-Tabelle der Bestellpositionen mit Zeilen ohne Information füllt. In einer Tabelle, die mit jeder Position jeder Bestellung wächst, ist das eine echte Überlegung und keine Mikro-Optimierung.

Bei einer Erstattung neu zu berechnen ist die konsequente Wahl, wenn man die Summe einer Bestellung als etwas betrachtet, das nach einer Änderung mit den aktuellen Produktdaten übereinstimmen soll. Die Alternative – Erstattungen, die eine teilweise veraltete Kostensumme stehen lassen – ist ebenfalls vertretbar, aber nicht offensichtlich richtiger.

Bei ausgeschalteter Funktion null zu liefern ist das, was eine deaktivierte Funktion überall sonst in WooCommerce tun sollte. Zerstörerisch wird es erst in Verbindung mit der ersten Entscheidung.

Den Preis für alle drei zahlen diejenigen, die die Bestellposition als unveränderlichen historischen Beleg behandeln. Das hat der Kern nie versprochen. Man nimmt es nur sehr leicht an, weil eine Momentaufnahme der Kosten genau so aussieht.

Wenn Sie auf diesen Daten aufbauen

• Behandeln Sie einen fehlenden Wert als unbekannt, nie als null. Die Datenbank kann Ihnen nicht sagen, welcher Fall vorliegt, und ein Bericht, der null annimmt, erfindet Rohertrag.
• Zeigen Sie die Abdeckung neben jeder Zahl. „Der Wareneinsatz ist für 74 % des Umsatzes bekannt“ ist der Unterschied zwischen einer Zahl, nach der jemand handeln kann, und einer genau wirkenden Zahl, die unbemerkt um ein Viertel danebenliegt.
• Lesen Sie „kein Wareneinsatz“ aus dem Produkt und die Abdeckung aus den Bestellpositionen. Wegen Falle 1 erzeugt jede andere Kombination Fehlalarme.
• Exportieren Sie monatlich. Eine CSV-Datei vom Monatsende ist der einzige Beleg Ihrer Kostenhistorie, den keine Erstattung neu schreiben kann. Das ist die nützlichste Gewohnheit auf dieser Seite.
• Versprechen Sie keine unveränderliche Kostenhistorie, wenn Sie sie nicht selbst speichern. Der Kern bietet sie nicht, und sie aufzubauen heißt, in den Shop zu schreiben statt aus ihm zu lesen: eine andere Stufe der Verantwortung und eine Entscheidung, die man bewusst treffen sollte.

Selbst nachprüfen

Alles hier lässt sich im Quellcode von WooCommerce lesen: save_cogs_data() in includes/data-stores/abstract-wc-order-item-type-data-store.php, wc_create_refund() in includes/wc-order-functions.php und calculate_cogs_total_value_core() in includes/abstracts/abstract-wc-order.php. Version 11.0.1, gelesen im September 2026.

Verhält sich etwas davon in Ihrem Shop oder in einer späteren Version anders, sagen Sie es uns: Diese Seiten werden korrigiert, wenn sie sich als falsch erweisen, und eine datierte Korrektur nützt allen mehr als eine Seite, die unbemerkt veraltet. Wie dieselben drei Tatsachen die Zahlen in unserem eigenen Bericht prägen, steht unter so wird der Rohertrag berechnet.