Lesbare Empfänger-Namen statt Rohtext (#4) #11

Merged

glow merged 1 commit from feature/4-merchant-name-cleanup into main

2026-07-08 20:15:21 +00:00

glow commented

2026-07-08 19:27:36 +00:00

(Migrated from gitlab.fluffyplace.de)

Schließt #4.

Was

Neue Spalte merchant_name, die beim Import per extractMerchantName() aus dem rohen comdirect-buchungstext abgeleitet wird. Abgedeckt sind alle Fälle aus den Beispielen, die du an #4 angehängt hast:

Auftraggeber: X Buchungstext: ... → X
Empfänger: X Kto/IBAN: ... — auch ohne Leerzeichen vor Kto/IBAN: (z.B. "Jasmin KreinKto/IBAN:")
PayPal: Auftraggeber ist immer "PayPal Europe S.a.r.l. et Cie S.C.A" — der eigentliche Händler wird stattdessen aus dem eingebetteten PP.xxxx.PP/.-Muster gezogen (z.B. "Apple Se rvices" statt "PayPal")
Kartenzahlungen ohne Auftraggeber-Label (US-Anbieter wie Anthropic/OpenRouter): Name direkt nach Buchungstext:, inkl. Erhalt von Rechtsform-Zusätzen wie , INC

Der rohe buchungstext bleibt erhalten (Tooltip beim Hover). merchant_name ist:

in der Transaktionsliste inline editierbar (klicken zum Bearbeiten)
Basis für die Top-Empfänger-Statistik im Dashboard
als drittes Feld (Empfänger) für Kategorisierungs-Regeln nutzbar, zusätzlich zu Buchungstext/Vorgang
in der Import-Vorschau sichtbar statt des Rohtexts

Tests

11 Unit-Tests für extractMerchantName (backend/src/services/merchantName.test.ts), inkl. aller oben genannten Fälle 1:1 aus deinen Beispielen. Zusätzlich end-to-end gegen einen laufenden Server verifiziert (Import → Regel-Treffer auf merchant_name → manuelles Überschreiben).

DB-Migration

merchant_name wird über ein idempotentes ALTER TABLE ... ADD COLUMN ergänzt (ensureColumn in db.ts), bestehende Datenbanken brechen also nicht. Die rules.field-CHECK-Constraint wurde um 'merchant_name' erweitert — das greift nur bei neu angelegten DBs (SQLite kann CHECK-Constraints nicht per ALTER ändern), was hier unkritisch ist, da noch keine Deployment-Daten existieren.

Schließt #4. ## Was Neue Spalte `merchant_name`, die beim Import per `extractMerchantName()` aus dem rohen comdirect-`buchungstext` abgeleitet wird. Abgedeckt sind alle Fälle aus den Beispielen, die du an #4 angehängt hast: - `Auftraggeber: X Buchungstext: ...` → `X` - `Empfänger: X Kto/IBAN: ...` — **auch ohne Leerzeichen** vor `Kto/IBAN:` (z.B. `"Jasmin KreinKto/IBAN:"`) - **PayPal**: Auftraggeber ist immer "PayPal Europe S.a.r.l. et Cie S.C.A" — der eigentliche Händler wird stattdessen aus dem eingebetteten `PP.xxxx.PP/.`-Muster gezogen (z.B. "Apple Se rvices" statt "PayPal") - Kartenzahlungen **ohne** Auftraggeber-Label (US-Anbieter wie Anthropic/OpenRouter): Name direkt nach `Buchungstext:`, inkl. Erhalt von Rechtsform-Zusätzen wie `, INC` Der rohe `buchungstext` bleibt erhalten (Tooltip beim Hover). `merchant_name` ist: - in der Transaktionsliste inline editierbar (klicken zum Bearbeiten) - Basis für die Top-Empfänger-Statistik im Dashboard - als drittes Feld (`Empfänger`) für Kategorisierungs-Regeln nutzbar, zusätzlich zu Buchungstext/Vorgang - in der Import-Vorschau sichtbar statt des Rohtexts ## Tests 11 Unit-Tests für `extractMerchantName` (`backend/src/services/merchantName.test.ts`), inkl. aller oben genannten Fälle 1:1 aus deinen Beispielen. Zusätzlich end-to-end gegen einen laufenden Server verifiziert (Import → Regel-Treffer auf `merchant_name` → manuelles Überschreiben). ## DB-Migration `merchant_name` wird über ein idempotentes `ALTER TABLE ... ADD COLUMN` ergänzt (`ensureColumn` in `db.ts`), bestehende Datenbanken brechen also nicht. Die `rules.field`-CHECK-Constraint wurde um `'merchant_name'` erweitert — das greift nur bei neu angelegten DBs (SQLite kann CHECK-Constraints nicht per ALTER ändern), was hier unkritisch ist, da noch keine Deployment-Daten existieren.

glow commented

2026-07-08 19:37:56 +00:00

(Migrated from gitlab.fluffyplace.de)

mentioned in merge request !12