Kevin
ac3bd6e8ea
Feedback-Umsetzung (dev/2026-07-22/feedback-analyse-2026-07-24.md, alle 10 Punkte):
- VIP-Statistik: eigener Berater ('ich', Linie 0) in Neue-Kundenabos- und beiden Top-10-Listen; Top-10-Umsatz sortiert nach abgerechneten Ist-Punkten + Abo-Anzahl-Spalte; Fußnote nicht-payline-wirksame Punkte (SalesVolumePoints::nonPaylinePoints)
- Führungskräfte-Liste: beide Sichten 'direkt' (an nächster FK abgeschnitten, additiv) und 'gesamt' (komplette Downline), Gesamt-Spalte nach Kundenzählweise
- Team-Abos: je Ebene 'abgerechnet (Monat)' und 'bis zum 25. erwartet'; Payline-Karte mit Teamabo-/Kundenabo-Zählern
- Incentive-Live-Ranking: Qualifizierte zuerst nummeriert (fixt auch isWinner rank<=max_winners)
- Porto: Netto-/Brutto-Kennzeichnung (Berater netto, Endkunden inkl. MwSt., portal_view-Flag; auch CRM-/Shop-Warenkorb + Checkout), Yard::shipping_tax-Fix
- Struktur-Ansicht: Abo-Badges 'A' (eigenes Abo) und '(n)' (Kundenabos) je Teampartner, gebatcht
- Abo-Löschung: Softdelete setzt active=0 (UserAbo deleting-Hook) + Bereinigungs-Migration für gelöschte-aber-aktive Abos
- Doku: technische Analyse + Kundinnen-Feedback-Dokument unter dev/2026-07-22/
- Tests: IncentiveRankingTest, TeamStructureAboBadgesTest, YardShippingTaxTest (neu); BackofficeStatisticsListsTest, TeamAboOverviewTest, PaylineForecastServiceTest, AboAdminDeleteTest, AboOneTimeViewTest erweitert
Außerdem enthalten (Branch-WIP vor dem Feedback): DATEV-Abgleich-Fixes 08+09/2025, USt-ID-Live-Validierung sowie restliche unkommittete Stände (u. a. Abo-Pause-Sprachkeys).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
6.2 KiB
Rückmeldung zum Abgleich 08+09/2025 (DATEV-Export MIVITA)
Datum: 17.07.2026 Bezug: Abgleich-Listen zu den Konten 4764, 8125, 8300 und 8400 für August/September 2025
Vielen Dank für den detaillierten Abgleich. Alle gemeldeten Abweichungen wurden im System nachvollzogen. Es handelte sich um fünf technische Ursachen im Export bzw. in der Datenhaltung — die Buchungen im Steuerbüro waren in nahezu allen Fällen korrekt, die Testdaten (unser DATEV-Export) fehlerhaft. Die Ursachen sind behoben; die Exporte für 08/2025 und 09/2025 werden neu erstellt und ersetzt.
1. Beträge über 1.000 € waren im Export drastisch zu niedrig
Betraf: 202536817, 202536968, 202537532 (Konto 8400)
Ein Formatierungsfehler beim Speichern der Steuer-/Nettobeträge (Tausendertrennzeichen) führte dazu, dass z. B. aus 1.434,70 € netto im Export 1,43 € wurden. Die Rechnungen selbst (PDF/Beleg) waren korrekt — nur der Exportbetrag war falsch.
Jetzt: Der Fehler ist an der Quelle und im Export behoben. Im neuen Export stimmen diese Positionen mit den Belegen überein.
2. Kontenzuordnung 8125 (steuerfreie igL) ↔ 8400/8300
Betraf u. a.: 202536848, 202536858, 202536910, 202537173, 202537290, 202538011, 202538144, 202538445, 202538446, 202539399 (gehörten auf 8125) sowie 202536841, 202537251, 202537460, 202537543, 202538398 (gehörten auf 8400/8300)
Zwei Ursachen:
- Der Export ermittelte die Steuerbehandlung aus dem heutigen Kundenstammsatz statt aus der tatsächlichen Rechnungsstellung. Hatte ein Berater seine USt-ID nach dem Kauf wieder entfernt, buchte der Export die (korrekt steuerfrei ausgestellte) Rechnung fälschlich auf 8400 — und umgekehrt.
- Hinterlegte USt-IDs wurden nicht validiert: Auch deutsche USt-IDs, offensichtliche Platzhalter (z. B. „DE123456789") und formal ungültige Nummern führten zur igL-Buchung auf 8125.
Jetzt:
- Maßgeblich für die Kontenzuordnung ist, wie die Rechnung tatsächlich ausgestellt wurde: ohne USt verkaufte EU-Lieferungen → 8125 (BU 1); mit USt berechnete Lieferungen → 8400/8300 nach Steuersatz. Der Export entspricht damit dem Beleg.
- Deutsche USt-IDs werden systemweit nicht mehr als Grundlage für steuerfreie Lieferungen akzeptiert (weder bei der Eingabe noch im Export).
- Die USt-ID wird bei jeder Bestellung erneut live über die EU-Datenbank (VIES) geprüft. Ist sie ungültig oder abgelaufen, wird die Bestellung automatisch mit Umsatzsteuer berechnet und der Kunde darauf hingewiesen. Der Fall „einmal validiert, dauerhaft steuerfrei trotz abgelaufener ID" (z. B. ESY9284953M, validiert 2023) kann damit nicht mehr auftreten.
3. Doppelt vergebene Rechnungsnummern
Betraf: 202537208, 202537572, 202538182, 202538332
Diese vier Nummern wurden im Zeitraum tatsächlich jeweils für zwei verschiedene Rechnungen vergeben (technischer Fehler bei zeitgleicher Rechnungserstellung). Im Export erschienen deshalb unter einer Belegnummer die Positionen beider Rechnungen — daher die nicht zuordenbaren Beträge.
Jetzt: Die Nummernvergabe ist technisch gegen Doppelvergabe gesichert (für Rechnungen bereits seit längerem, jetzt auch für Gutschriften, die denselben Nummernkreis nutzen). Die vier Altfälle bleiben in den Daten bestehen; im neuen Export sind die betroffenen Positionen weiterhin unter derselben Nummer als getrennte Zeilen erkennbar. Falls für die Verbuchung eine Aufstellung der jeweils zwei Einzelrechnungen benötigt wird, liefern wir diese gern nach.
4. Gutschriften auf Konto 4764 (GS202536995, GS202538597)
Beide Provisionsgutschriften wurden ohne Umsatzsteuer ausgestellt (Empfänger nicht USt-pflichtig / Ausland). Der Export übergab sie jedoch mit dem Steuerschlüssel für 19 %, wodurch DATEV rechnerisch die USt herausrechnete (56,70 statt 67,47 bzw. 12,50 statt 14,88).
Jetzt: Der Steuerschlüssel wird aus dem Steuerstatus zum Zeitpunkt der Gutschriftserstellung übernommen — also so, wie er auf dem Beleg ausgewiesen ist.
5. Stornierte Rechnungen aus 2025
Betraf: 202536978, 202537144, 202539501 (voll storniert), 202537513 (teilstorniert)
Diese Stornierungen wurden 2025 außerhalb des Systems abgewickelt und sind dort nicht als Storno erfasst; der Export enthielt daher die vollen Beträge. Systemseitige Stornorechnungen gibt es erst seit Anfang 2026 — seither erscheinen Stornos automatisch als eigene Belegzeilen im Export.
Für die Altfälle: Die Verbuchung im Steuerbüro (Betrag 0 bzw. Teilbetrag) ist korrekt; hier bitten wir, die Abweichung zum Export einmalig manuell zu berücksichtigen.
6. Belege außerhalb unseres Nummernkreises
Betraf: 202506145, 202506147 (ggf. weitere, inkl. einzelner Stornorechnungen)
Diese Rechnungen stammen nicht aus dem Shopsystem, sondern aus einem separaten Rechnungskreislauf des Unternehmens. Sie können und werden im DATEV-Export des Shops nicht auftauchen und sollten im Abgleich als „extern" gekennzeichnet werden.
Einzelfälle
- 202539011 („Rechnung liegt uns nicht vor"): Die Rechnung existiert im System (Positionen 66,22 € zu 7 % und 285,18 € zu 19 %); das PDF wird nachgereicht.
- Cent-Differenzen (0,01–0,09 €, z. B. 202537808, 202538011, 202538182): Rundungsdifferenzen bei der Netto-Aufteilung je Steuersatz; im neuen Export weitgehend bereinigt, Restdifferenzen im Centbereich können vereinzelt verbleiben.
Zusammenfassung / nächste Schritte
| Thema | Status |
|---|---|
| Beträge > 1.000 € | behoben, neuer Export korrekt |
| Kontenzuordnung 8125/8400/8300 | behoben, folgt jetzt dem Beleg |
| USt-ID-Prüfung | ab sofort Live-Prüfung (VIES) bei jeder Bestellung, keine deutschen USt-IDs |
| Doppelte Rechnungsnummern | Ursache behoben; 4 Altfälle dokumentiert |
| Gutschriften 4764 | behoben, Steuerschlüssel laut Beleg |
| Stornos 2025 | Altfälle: bitte manuell berücksichtigen; ab 2026 automatisch im Export |
| Externe Belege | nicht Teil des Shop-Exports, als „extern" markieren |
Die korrigierten DATEV-Exporte für 08/2025 und 09/2025 werden nach Einspielen der Änderungen neu generiert und bereitgestellt. Bei Rückfragen zu einzelnen Belegen liefern wir gern Detailauswertungen nach.