Kontakt zusammenführen

Benötigte Berechtigung:documents:write(Nicht an DATEV exportierte Belege ändern)

Verschiebt die Belege des Kontakts {id} zum Kontakt targetContactId, wie „Mit anderem Kontakt zusammenführen“ in der App, höchstens 50 Belege je Aufruf, die ältesten zuerst; remaining nennt, was danach noch beim Kontakt bleibt. Jeder Beleg bekommt Name, USt-IdNr., IBAN, Adresse und Nummer des Kontakts wie bei counterparty.contactId in PATCH /api/document/{id}, und bimetrics bucht ihn sofort auf das Personenkonto des Kontakts um. Liegt eine Buchung in einem festgeschriebenen Monat, storniert bimetrics sie dort und bucht sie neu; reversedFinalizedMonths nennt die Monate. Ist ein Beleg einem Bankumsatz zugeordnet, bucht bimetrics die ganze Zuordnung neu. Trägt der Beleg genau die Kostenstelle, die am alten Kontakt für neue Belege hinterlegt ist (defaultCostCenterId), oder hat er keine, bekommt er die des neuen Kontakts oder keine. Jede andere bleibt. Übersprungen werden ausgestellte Rechnungen (issued, sie bleiben bei dem Kunden, an den sie gingen), an DATEV exportierte Belege, auch über eine Zuordnung (exported), Belege aus Dauerbuchungen (contract) oder Buchungsvorlagen (linked), Belege einer Zuordnung mit weiteren Belegen (collective, erst die Zuordnung lösen), Belege mit erfasster Bar- oder Privatzahlung (paid), Belege unter „Belegtyp prüfen“ (kindReview), Belege, die danach einen Buchungsfehler hätten, etwa Reverse Charge ohne USt-IdNr. am Kontakt (issues), noch nicht gelesene (reading), stornierte (deleted), Belege, die keine Rechnung und kein Eingangsbeleg sind (otherKind), und Belege, die schon beim Zielkontakt sind (unchanged). Dazu notFound und notPreviewed. Mit deleteSource löscht bimetrics den Kontakt danach, wenn nichts mehr auf ihn verweist, weder ein Beleg noch eine Vorlage, Dauerbuchung, ein Angebot oder ein Entwurf, so wie das Löschen eines Kontakts in der App (sourceDeleted). Ohne deleteSource bleibt er bestehen. Höchstens 50 Belege je Aufruf (400 BulkLimitExceeded). Die Antwort nennt je Beleg, was geschah: change geändert, skipped mit Grund übersprungen, failed mit Code abgelehnt. Das ist ein Teilerfolg wie in der App: Ein abgelehnter Beleg hält die anderen nicht auf, und die Route antwortet mit 200. Mit dryRun ändert sie nichts und zeigt, was geschähe, mit einer version je Beleg. Zum Ausführen gibst du diese als expectedVersions zurück, sonst antwortet die Route mit 400 ExpectedVersionRequired. Es ändert sich nur, was unter change stand und seitdem unverändert ist: Ein geänderter Beleg kommt mit VersionConflict in failed, die übrigen laufen, und ein Beleg ohne Eintrag bleibt mit notPreviewed in skipped. Jeder Beleg läuft als eigener Befehl mit eigenem Eintrag im Protokoll und zählt einzeln auf die Tagesgrenzen der Firma und der Testphase. Der ganze Aufruf zählt einmal auf die Grenzen je Minute. Eine Wiederholung mit gleichem Idempotency-Key ändert nichts doppelt und erledigt, was noch offen ist. Sie klärt auch den Stand, wenn ein Aufruf abbricht: OutcomeUnknown heißt, der Beleg kann schon gebucht sein.

Benötigt einen Schlüssel mit der Berechtigung documents:write.