Sieben Linien über die letzten 14 Monate plus Live: "Gesamt gebundenes Warenkapital" (dick, inkl. WE-/Rechnung-Korrektur), "Gesamtlagerwert" (Summe aller Lagergruppen OHNE diese Korrektur — reiner physischer Lagerwert), sowie jede einzelne Lagergruppe (Amazon, Fulfillment Regensburg, Eigenes Lager, B2B Lager, Kommissions Lager EH). Eigenes Lager/B2B Lager/Kommission (und damit auch Gesamt und Gesamtlagerwert) haben vor Juni 2026 eine echte Lücke, keine 0 (historisch nicht erfasst, siehe Hinweis unten). Eine Wasserfall-/Ursachenanalyse (Wareneingänge/Verkäufe/Retouren) ist noch nicht möglich, dafür fehlen kategorisierte Lagerbewegungsdaten über die Zeit.
Nach Lager: JTL-Bestand, maßgeblich für die Summe (Ausnahme AWD, kein JTL-Äquivalent). Nach Status: Amazon-native Quelle, nur zur Information — weicht in der Summe leicht ab, siehe Inventur_Ergebnis.md.
Nur Belege (Fremdbelegnummer) mit mindestens einer Anzahlung, eine Zeile je Beleg — ein Beleg kann mehrere JTL-Bestellungen zusammenfassen (Bestellsumme ist dann die Summe aller zugehörigen Bestellungen). Quelle: JTL Wawi → Beschaffung → Eingangsrechnungen/Zahlungen. Zeile anklicken zeigt die gesamte Zahlungshistorie zu diesem Beleg (Anzahlung UND Restzahlung/sonstige Zahlungen, mit Typ und Datum) — "Restsumme (offen)" berücksichtigt bereits alle diese Zahlungen, nicht nur die als Anzahlung geflaggten. "Zoll/Fracht (n. Bestellsumme)" (Fund 2026-07-31, Beleg "INV26-LF210+INV26-LF209+INV26-LF208"): alle Zusatzkosten aus JTLs Zusatzkostenverteilung (Zollgebühren, Frachtkosten Hersteller u.a., unabhängig vom "Beeinflusst Gesamtsumme"-Flag — Martin hat für diesen Beleg bestätigt, dass beide Kostenarten zusammen zur echten Netto-Gesamtsumme gehören) — stecken nicht in der Bestellsumme, wurden aber real mitbezahlt, und fließen daher zusätzlich in die Restsumme ein. "Zollgeb. (autom. verrechnet)": der Zollgebühren-Anteil davon gilt automatisch als bezahlt (mit Martin abgestimmt, 2026-07-31) — Zollgebühren werden an unseren Importeur entrichtet, nicht an den Hersteller, und erscheinen deshalb nie als Zahlung in JTL. Ohne diesen Ausgleich bliebe dieser Anteil dauerhaft als "offen" stehen, obwohl er längst bezahlt ist. "Zahlungen Gesamt (JTL)" zeigt weiterhin nur die echten, in JTL erfassten Zahlungen (identisch mit der Zahlungshistorie beim Anklicken der Zeile) — "Zahlungen JTL inkl. Zollgeb." ist die Summe aus beidem und damit die Zahl, die tatsächlich in die Restsumme einfließt ("Restsumme (offen)" = Bestellsumme + Zoll/Fracht − Zahlungen JTL inkl. Zollgeb.). "Bereits im Lagerbestand" (Gegenprüfung, mit Martin abgestimmt 2026-07-31): wie viel Wert der fakturierten Ware JETZT schon im aktuellen Lagerbestand steckt, unabhängig vom Zahlungsstatus — hoch trotz offener Restsumme heißt "Ware ist da, Zahlung klären"; niedrig/0 trotz offener Restsumme heißt "Ware ist noch nicht angekommen, die offene Anzahlung ist normal". "Zahlungen JTL inkl. Zollgeb. abzgl. Bestand" = "Zahlungen JTL inkl. Zollgeb." minus "Bereits im Lagerbestand" — wie viel bereits gezahltes Geld (inkl. Zollgebühr) noch NICHT durch physisch eingebuchte Ware gedeckt ist. Hoch = reines Vorkasse-Risiko (viel bezahlt, Ware noch nicht da); niedrig/negativ = die eingebuchte Ware deckt die Zahlung bereits ganz oder teilweise ab.
Ø-EK/letzter EK/Lieferanten-EK sind immer der AKTUELLE Stand aus JTL (keine
historische Preisverfolgung im Data Lake) — unabhängig vom oben gewählten
Zeitraum, nur Bestand/Lagerwert folgen dem Zeitraum. "Lagerwert je Lieferant"
gruppiert je Artikel über den in JTL hinterlegten STANDARD-Lieferanten (nicht
abschließend mit Martin abgestimmt) — Artikel ohne Standard-Lieferant laufen unter
"Kein Standard-Lieferant hinterlegt". "EK-Auffälligkeiten" zeigt Artikel mit mehr
als 30% Abweichung zum vorletzten Einkauf (Lastenheft-Vorgabe) — Fälle, bei denen
einer der beiden Einkäufe mit 0 € gebucht ist (Datenrand-Artefakt, kein echter
Preissprung), sind bewusst herausgefiltert.
Bewertungshierarchie (seit 2026-09-21): fehlt der Ø-EK eines
Artikels, greift der Lagerwert zuerst auf den letzten Einkaufspreis zurück, fehlt
auch dieser, auf den EK des in JTL hinterlegten Standard-Lieferanten
("Hersteller-EK"). "Ø-EK fehlt im Artikelstamm" listet trotzdem JEDEN Artikel ohne
gepflegten Ø-EK — unabhängig davon, ob einer der beiden Fallbacks bereits einen
Wert liefert — damit diese Artikelstamm-Lücke sichtbar bleibt; Spalte
"Bewertet über" zeigt, welche Stufe den tatsächlich verwendeten Lagerwert liefert.
"EK = 0, aber Bestand vorhanden" bleibt die engere Lastenheft-Fehlerliste: nur
Artikel, für die auch KEIN Fallback einen Wert findet.