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>
This commit is contained in:
Guido
2026-08-27 10:13:52 +02:00
co-authored by Claude Opus 5
parent 90bda6b161
commit 8ceee5c5b1
8 changed files with 468 additions and 103 deletions
+34 -1
View File
@@ -8,13 +8,15 @@ Kurs (``fx_rate``) hat Vorrang vor dem EZB-Kurs.
from datetime import date
from fastapi import APIRouter, Depends, HTTPException, Query, status
from pydantic import BaseModel
from sqlalchemy.orm import Session
from ..database import get_db
from ..deps import get_current_user, get_owned
from ..models import Account, Category, Transaction, TxnType, User
from ..schemas import TransactionCreate, TransactionOut, TransactionUpdate
from ..services import buchung, currency
from ..services import buchung, currency, uebertrag_buchen
from ..services.uebertrag_buchen import UebertragFehler
from .accounts import base_currency
router = APIRouter(prefix="/transactions", tags=["transactions"])
@@ -207,6 +209,37 @@ def update_transaction(
return to_out(db, txn, base_currency(db, user), _currency_map(db, user))
class TransactionTransferIn(BaseModel):
to_account_id: int
# Nur setzen, wenn man es besser weiss als Certain – siehe uebertrag_buchen.
trotzdem: bool = False
@router.post("/{txn_id}/transfer", response_model=TransactionOut)
def make_transfer(txn_id: int, payload: TransactionTransferIn,
db: Session = Depends(get_db), user: User = Depends(get_current_user)):
"""Eine gebuchte Ausgabe oder Einnahme zum Kontoübertrag machen.
Nicht über PATCH: Der dreht die Richtung bei einer Einnahme nicht um und
legt keine Gegenseite auf dem Zielkonto an. Beides gehört zusammen, deshalb
läuft es durch denselben Dienst wie der Weg aus dem Eingang.
"""
txn = get_owned(db, Transaction, txn_id, user)
ziel = get_owned(db, Account, payload.to_account_id, user)
try:
uebertrag_buchen.aus_buchung(db, user, txn, ziel, payload.trotzdem)
except UebertragFehler as e:
db.rollback()
raise HTTPException(
status_code=status.HTTP_409_CONFLICT if e.nachfragen
else status.HTTP_400_BAD_REQUEST,
detail=str(e),
) from e
db.commit()
db.refresh(txn)
return to_out(db, txn, base_currency(db, user), _currency_map(db, user))
@router.delete("/{txn_id}", status_code=status.HTTP_204_NO_CONTENT)
def delete_transaction(
txn_id: int, db: Session = Depends(get_db), user: User = Depends(get_current_user)