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.