feat: Ein Uebertrag faengt seine Gegenseite ab

Ein Uebertrag legte auf dem Zielkonto nichts an. Der Duplikatschutz konnte die
Gegenseite deshalb nicht sehen – er vergleicht import_hash, den eine
Uebertrags-Buchung nicht hat, und Eingangs-Eintraege, die es dort nicht gab.
Die schon vorliegende Gegenseite liess sich ein zweites Mal buchen, die
spaeter von der Bank gelieferte kam ungeprueft an: das Geld zweimal auf dem
Zielkonto.

Jetzt entsteht auf dem Zielkonto ein Eingangs-Eintrag, der auf DIESELBE Buchung
zeigt. Liegt dort schon ein passender offener Eintrag, wird dieser verbraucht
statt einen zweiten anzulegen – ueber denselben Abgleich wie beim Import, nicht
ueber eine zweite Vergleichslogik. Damit greift auch der vorhandene Schutz
gegen die spaeter eintreffende Gegenseite, ohne dass etwas Neues dafuer gebaut
werden musste.

Die Uebertrags-Logik liegt dafuer in einem eigenen Dienst. Zwei Wege fuehren
hinein – ein offener Vorschlag und eine schon gebuchte Buchung – und beide
brauchen dieselben vier Regeln. Der PATCH-Weg des Buchungs-Routers taete es
nicht: Er dreht die Richtung bei einer Einnahme nicht um und legt keine
Gegenseite an.

Die Sperre richtet sich nicht mehr nach der Waehrung, sondern danach, ob der
Betrag der Gegenseite BEKANNT oder geschaetzt ist. Bei gleicher Waehrung ist er
exakt, die Gegenseite wird sicher wiedererkannt – dann geht ein Uebertrag auf
ein angebundenes Konto ohne Nachfrage durch. Ueber Waehrungen hinweg bleibt die
Warnung, weil der EZB-Kurs nicht der Kurs der Bank ist.

Und Verwerfen raeumt beide Seiten: Bei einem Uebertrag zeigen zwei Eintraege
auf dieselbe Buchung, und der Fremdschluessel haette die andere als 'gebucht'
ohne Buchung zurueckgelassen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/app/routers/inbox.py

@@ -22,7 +22,8 @@ from ..models import (
 )
 from ..schemas import ApiTokenCreate, ApiTokenCreated, ApiTokenOut, InboxItemOut
 from ..security import generate_session_token, hash_session_token
-from ..services import eingang
+from ..services import eingang, uebertrag_buchen
+from ..services.uebertrag_buchen import UebertragFehler
 
 router = APIRouter(prefix="/inbox", tags=["inbox"])
 
@@ -72,6 +73,19 @@ def delete_token(token_id: int, db: Session = Depends(get_db), user: User = Depe
 # --- Eingang -----------------------------------------------------------------
 
 
+def _uebertrags_fehler(e: UebertragFehler) -> HTTPException:
+    """409, wenn sich der Fehler mit ``trotzdem`` übergehen lässt, sonst 400.
+
+    Der Unterschied ist der Oberfläche wichtig: 409 heisst nachfragen und noch
+    einmal senden, 400 heisst, es geht so nicht.
+    """
+    return HTTPException(
+        status_code=status.HTTP_409_CONFLICT if e.nachfragen
+        else status.HTTP_400_BAD_REQUEST,
+        detail=str(e),
+    )
+
+
 def _gegenkonten(db: Session, user: User, eintraege: list[InboxItem]) -> dict[int, int]:
     """Je Eintrag das Gegenkonto, falls seine Buchung ein Übertrag ist.
 
@@ -154,28 +168,12 @@ def book_as_transfer(item_id: int, payload: InboxTransferIn,
     Übertrag ist keine Ausgabe.
     """
     eintrag = get_owned(db, InboxItem, item_id, user)
-    if eintrag.account_id is None:
-        raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST,
-                            detail="Kein Konto zugeordnet")
     ziel = get_owned(db, Account, payload.to_account_id, user)
-    if ziel.id == eintrag.account_id:
-        raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST,
-                            detail="Ein Übertrag braucht ein anderes Zielkonto")
-
-    # Der teuerste Fehler an dieser Stelle: Das Zielkonto hängt selbst an einer
-    # Bank, liefert die Gegenbuchung also von allein. Wer hier trotzdem eine
-    # anlegt, hat das Geld zweimal auf dem Zielkonto.
-    if not payload.trotzdem and eingang.ist_angebunden(db, user, ziel):
-        raise HTTPException(
-            status_code=status.HTTP_409_CONFLICT,
-            detail=(f"'{ziel.name}' ist selbst an eine Bank angebunden und meldet "
-                    f"den Zugang von allein. Buche das hier als Ausgabe – beide "
-                    f"Seiten werden danach automatisch als Übertrag verbunden."),
-        )
-
-    if eingang.buche_als_uebertrag(db, user, eintrag, ziel) is None:
-        raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST,
-                            detail="Lässt sich nicht buchen")
+    try:
+        uebertrag_buchen.aus_eingang(db, user, eintrag, ziel, payload.trotzdem)
+    except UebertragFehler as e:
+        db.rollback()
+        raise _uebertrags_fehler(e) from e
     db.commit()
     db.refresh(eintrag)
     return _out(db, user, [eintrag])[0]
@@ -209,12 +207,23 @@ def discard_item(item_id: int, db: Session = Depends(get_db), user: User = Depen
     hat; so kann der Abgleich sie weiterhin erkennen.
     """
     eintrag = get_owned(db, InboxItem, item_id, user)
+    # Bei einem Übertrag zeigen ZWEI Einträge auf dieselbe Buchung. Löscht man
+    # sie, bliebe die andere Seite als „gebucht" ohne Buchung stehen – der
+    # Fremdschlüssel setzt nur ihre Verweisspalte auf NULL.
+    geschwister = (
+        db.query(InboxItem)
+        .filter(InboxItem.owner_id == user.id,
+                InboxItem.transaction_id == eintrag.transaction_id)
+        .all()
+        if eintrag.transaction_id is not None else [eintrag]
+    )
     if eintrag.transaction_id is not None:
         txn = db.get(Transaction, eintrag.transaction_id)
         if txn is not None and txn.owner_id == user.id:
             db.delete(txn)
-    eintrag.status = InboxStatus.discarded
-    eintrag.transaction_id = None
+    for e in geschwister:
+        e.status = InboxStatus.discarded
+        e.transaction_id = None
     db.commit()