import { Callout } from "zudoku/ui/Callout"; # Erweiterte Zahlungsvorschläge ## Geschäftswert Der Zahlungsvorschlag im Microsoft Dynamics 365 Business Central Standard erzeugt Zahlungen für **Kreditoren**. Rückzahlungen an Debitoren – etwa aus Gutschriften oder Überzahlungen – und Auslagenerstattungen an **Mitarbeiter** müssen dagegen manuell erfasst werden. Zudem sind alle Einstellungen des Vorschlags bei jedem Lauf neu anzugeben, was bei wiederkehrenden Zahlungsläufen fehleranfällig ist. Bestehen mit einem Geschäftspartner gleichzeitig Forderungen und Verbindlichkeiten, ist außerdem eine **Aufrechnung** üblich, um nur den Restbetrag zu zahlen. Im Standard ist dies vollständig manuell abzuwickeln – inklusive der erforderlichen Aufrechnungserklärung. Der **erweiterte Zahlungsvorschlag** in 365 business Banking deckt alle drei Kontenarten ab, speichert die Einstellungen in Vorlagen und beherrscht die Debitor-Kreditor-Aufrechnung samt Nachweis. ## Funktionsbeschreibung Im **Zlg.-Ausg. Buch.-Blatt** steht die Aktion **Erw. Zahlungsvorschlag** zur Verfügung. Sie erzeugt Buch.-Blattzeilen für **Debitoren**, **Kreditoren** und **Mitarbeiter** in einem Lauf. Der Aufruf verlangt nur zwei Angaben: - **Vorlagencode** – die Vorlage, die die Voreinstellungen des Vorschlags liefert. - **Letztes Fälligkeitsdatum** – begrenzt die berücksichtigten Posten. Leer bedeutet keine Begrenzung. ### Erweiterte Zahlungsvorschlagsvorlage Alle weiteren Einstellungen werden in der **Erw. Zahlungsvorschlagsvorlage** hinterlegt und sind damit wiederverwendbar: | Bereich | Felder | |---|---| | Umfang | **Debitorenzahlungen vorschlagen**, **Kreditorenzahlungen vorschlagen**, **Mitarbeiterzahlungen vorschlagen** | | Auswahl | **Fälligkeitsdatum Formel**, **Skonto finden**, **Kreditorenpriorität verwenden**, **Verfügbarer Betrag (MW)** | | Zusammenfassung | **Pro Konto zusammenfassen**, **Neue Belegnr. pro Zeile** | | Buchung | **Fälligkeitsdatum als Buchungsdatum verwenden** | | Aufrechnung | **Debitor-Kreditor-Aufrechnung anwenden** | | Verwendungszweck | **Debitor-Nachricht an Empfänger**, **Kreditor-Nachricht an Empfänger**, **Mitarbeiter-Nachricht an Empfänger** | | Feinsteuerung | **Debitorenposten-Filter**, **Kreditorenposten-Filter**, **Mitarbeiterposten-Filter** | Die drei Felder **Nachricht an Empfänger** werden – wie der Buchungstext der Kontierungsregeln – aus Platzhaltern in geschweiften Klammern zusammengesetzt: `{Document No.}`, `{Account No.}`, `{Account Name}`, `{External Document No.}`, `{Applied Amount}`, `{Document Type}` und `{Document Type Short}`. Bleibt ein Feld leer, wird auf Belegart und externe Belegnummer zurückgegriffen. Fasst eine Zahlung mehrere Belege zusammen, werden die Belegnummern **je Belegart** gruppiert – z. B. `Gutschrift EGU-1051, Rechnung 2026257, 2026345`. ### Gutschriften Gutschriften werden **verrechnet, nicht ausgezahlt** – eine negative Zahlung gibt es nicht. Hält ein Konto Gutschriften, entsteht deshalb **eine einzige Zahlungszeile** über den verrechneten Betrag, die alle Posten des Kontos ausgleicht. Das gilt auch dann, wenn **Pro Konto zusammenfassen** nicht gesetzt ist: Bekäme jede Rechnung eine eigene Zeile, würde sie in voller Höhe gezahlt und der Geschäftspartner wäre um die Gutschrift überzahlt. Konten ohne Gutschriften behalten unverändert eine Zeile je Posten. Übersteigen die Gutschriften die offenen Verbindlichkeiten, entsteht **keine** Zahlungszeile. Die Posten bleiben offen und werden im nächsten Lauf berücksichtigt, sobald wieder Rechnungen vorliegen – oder Sie gleichen sie manuell aus. Eine Zahlung, die Gutschriften verrechnet, wird nicht über mehrere Zeilen aufgeteilt, auch wenn **Verwendungszweck Überschreitungsoption** auf *Zahlung aufteilen* steht – eine Teilzahlung aus lauter Gutschriften wäre wieder negativ. Passt der Verwendungszweck nicht in die 140 Zeichen, wird stattdessen ein Zahlungsavis erstellt bzw. der Text gekürzt. ### Debitor-Kreditor-Aufrechnung Ist **Debitor-Kreditor-Aufrechnung anwenden** aktiv, prüft der Vorschlag für jeden Kreditor, ob der zugehörige Geschäftspartner – über die Kontakt-Geschäftsbeziehung verknüpft – auch als Debitor mit **offenen Forderungen** geführt wird. Der aufrechenbare Betrag ist der kleinere der beiden Werte aus offenen Forderungen und vorgeschlagener Verbindlichkeit. Die aufgerechneten Forderungen und Verbindlichkeiten werden über ein **Paar sich ausgleichender Buch.-Blattzeilen** beglichen – ohne Zahlung über die Bank. Nur der verbleibende Restbetrag wird tatsächlich gezahlt. Zu jedem Aufrechnungslauf entsteht ein **Aufrechnungsnachweis**, der die gegenseitigen Forderungen einzeln mit ihren Posten und den aufgerechneten Anteilen ausweist und als Aufrechnungserklärung (§§ 387 ff. BGB) dient. Über die Aktionen **Aufrechnungsnachweis drucken** und **Aufrechnungsnachweis senden** im Zlg.-Ausg. Buch.-Blatt geben Sie ihn aus. Aufgerechnet werden nur Posten in **Mandantenwährung**. Mitglieder eines [Zahlungsverbands](payment-groups.mdx) sind von der Aufrechnung ausgenommen, da deren Posten über das Zentralkonto des Verbands ausgeglichen werden. Ebenso ausgenommen sind Kreditoren mit **Gutschriften**: Die Gutschrift mindert bereits die Verbindlichkeit und wird über die Verrechnungszahlung des Kontos ausgeglichen – würde zusätzlich aufgerechnet, würde mehr beglichen als tatsächlich geschuldet ist. Ein gebuchter Aufrechnungsnachweis bleibt als Aufrechnungserklärung erhalten, auch wenn die zugrunde liegenden Buch.-Blattzeilen nicht mehr vorhanden sind. Die Übersicht **Aufrechnungsnachweise** führt alle Nachweise. ### Zahlungsformcode-Filter und Fallback Wenn im Anforderungsdialog des erweiterten Zahlungsvorschlags ein **Zahlungsformcode** als Filterkriterium gesetzt wird, bezieht der Vorschlag automatisch auch Posten **ohne eigenen Zahlungsformcode** ein. Technisch ergänzt der Code den gesetzten Filter um `|''`, sodass leere Werte mitkommen. Für diese Posten ohne eigenen Zahlungsformcode greift der **Zahlungsformcode des Buch.-Blatt-Stapels** (Feld *bdev.BNK Payment Method Code* im *Zlg.-Ausg. Buch.-Blatt*). Dieser Fallback-Wert wird auf die erzeugten Buch.-Blattzeilen übertragen. Bleibt der Zahlungsformcode-Filter im Dialog leer, kommen ohnehin alle Posten mit – unabhängig davon, ob sie einen Zahlungsformcode besitzen oder nicht. Kreditorenposten ohne Zahlungsformcode können auch nachträglich manuell mit einem Zahlungsformcode versehen werden. Der Vorschlag berücksichtigt dann den am Posten hinterlegten Wert. Weitere Informationen finden Sie im Artikel [Zahlungsausgang Buch.-Blatt](../../payment-journal.mdx).