Ein Kunde meldete sich mit einem dringenden Problem: Der tägliche Bankrückmeldebericht per E-Mail enthielt plötzlich 423 Zeilen, während dieselbe Abfrage im Portal 1.351 Zeilen anzeigte. Der Unterschied von 928 Einträgen löste sofortige Alarmstimmung aus – doch der Fehler lag nicht im Verlust, sondern im Timing.
Der erste Schritt: Daten vergleichen statt sofort zu debuggen
Bevor Code analysiert oder Logs durchforstet wurden, begann die Fehlersuche mit einem einfachen Vergleich der beiden Berichte. Die Ergebnisse waren aufschlussreich:
- Beide Dateien stammten vom gleichen Tag.
- Der gleiche Bankcode und identische Statusfilter wurden verwendet.
- Jede Zeile aus der E-Mail war auch im Portal enthalten.
Die Erkenntnis war klar: Die Daten waren nicht falsch, sondern nicht verfügbar – zum falschen Zeitpunkt.
Hypothesen systematisch widerlegen
Drei plausible Ursachen wurden nacheinander überprüft, jede mit produktiven Abfragen bestätigt oder verworfen:
- „Die Daten sind auf mehrere Banken oder Anhänge verteilt.“
Eine Prüfung ergab, dass alle 1.351 Zeilen dem gleichen Bankcode zugeordnet waren. Die Hypothese war damit widerlegt.
- „Die Duplikatsfilterung ist zu aggressiv.“
Der Bericht filtert bereits gesehene Rechnungen des Vortags aus:
$diff = array_diff(array_column($heute, 'invoice'), array_column($gestern, 'invoice'));Eine Testabfrage mit Produktionsdaten entfernte keine Zeilen. Der Fehler lag also nicht hier.
- „Die Abfragen nutzen unterschiedliche Datumsfilter.“
Beide Berichte nutzten denselben Filter auf die Spalte transaction_created_at für denselben Tag. Auch diese Annahme war falsch.
Die entscheidende Abfrage: Ein zeitliches Rätsel
Eine gezielte Datenbankabfrage brachte die Lösung:
SELECT COUNT(DISTINCT invoice) FROM bank_returns
WHERE DATE(occurrence_date) = '2026-06-23'
AND bank_code = 33
AND credit_date IS NOT NULL;Das Ergebnis: 1.351 Einträge – identisch mit dem Portal. Doch warum zeigte die E-Mail nur 423? Der Schlüssel lag nicht in der Logik, sondern im Zeitpunkt der Abfrage.
Die 16-Minuten-Falle: Synchronisation ist alles
Die Zeitstempel der Prozesse verrieten den Fehler:
- 07:15:45 Uhr: Der E-Mail-Bericht wird generiert und versendet.
- 07:31:02 Uhr: Die Bank liefert die Rückmeldedaten (~12.700 Einträge des Tages) an das System.
Der Bericht wurde 16 Minuten zu früh ausgeführt – noch bevor die meisten Daten importiert waren. Eine genauere Analyse:
- Vor 07:15 Uhr importierte Daten: 423 Zeilen (entsprechend dem E-Mail-Bericht)
- Nach 07:15 Uhr importierte Daten: 928 fehlende Zeilen
- Gesamtzahl: 1.351 Zeilen
Das Portal zeigte später alle Daten, weil es erst um 08:23 Uhr abgefragt wurde – nach Abschluss des Imports.
Die eigentliche Ursache: Zeitliche Kopplung statt Logikfehler
Der Fehler war kein Algorithmusproblem, sondern ein zeitliches Abhängigkeitsproblem. Der Bericht ging davon aus, dass alle Rückmeldungen des Vortags bis 07:15 Uhr vollständig importiert wären. Die Bank lieferte die Daten jedoch erst um 07:31 Uhr.
Lösungsansätze: Von einfach bis nachhaltig
Die Behebung des Problems erforderte keine Code-Änderungen, sondern eine Anpassung der Prozesse. Hier die besten Optionen, geordnet nach Aufwand:
- Einfachste Lösung: Den Bericht erst nach der morgendlichen Importroutine ausführen.
- Nachhaltiger: Den Bericht automatisch nach Abschluss des Imports starten, statt an einen festen Zeitplan zu binden.
- Defensivlösung: Der Bericht prüft vor dem Versand, ob die erwartete Importroutine erfolgreich abgeschlossen wurde.
Die zentrale Erkenntnis: Timing ist entscheidend
„Fehlende Daten“ sind in den meisten Fällen kein Verlust, sondern ein Zeitproblem. Bevor Debugging-Tools eingesetzt werden, sollten zwei Fragen gestellt werden:
- Wann entstehen die Daten?
- Wann werden sie abgefragt?
Die meisten vermeintlichen Datenverluste lassen sich bereits hier klären. Der Fall zeigt, wie wichtig es ist, Prozesse nicht nur auf Logik, sondern auch auf Synchronisation zu prüfen. Ein scheinbar einfacher Zeitversatz von 16 Minuten kann den Unterschied zwischen einem vollständigen und einem unvollständigen Bericht ausmachen – ohne dass ein einziger Fehler im Code vorliegt.
KI-Zusammenfassung
Raporlama sisteminizdekilerin bazı verileri eksik mi? 16 dakikalık bir zamanlama hatası, sabah 423 satır yerine 1.351 satırın görünmemesine neden olmuş. Sisteminizin nasıl çalıştığını anlamanın yolu, verinin kaynağına ve okunma zamanına odaklanmaktan geçiyor.
