Ein Beleg

Wichtig

Die hier genannten Funktionen sind alle oder teilweise im Rahmen einer Vorschauversion verfügbar. Inhalt und Funktionsweise unterliegen Änderungen. Weitere Informationen zu Vorschauversionen finden Sie unter Dienstupdateverfügbarkeit.

Was ist ein Beleg?

Aufgrund der Flexibilität von Finanzerfassungen können Sie einen einzelnen Beleg eingeben, der eine Transaktion darstellt, aber mehrere Debitoren, Kreditoren, Anlagen, Projekte oder Bankkonten aufweist. Microsoft bezeichnet diese Funktionalität als Ein Beleg. Die „Ein Beleg“-Szenarien enthalten keine Transaktionen, die nur Sachkonten beinhalten. Diese Transaktionen werden im Hauptbuch gebucht, nicht in Untersachkonten wie Debitorenbuchhaltung, Anlagen und Bank.

Es gibt zwei Kategorien von „Ein Beleg“-Beispielen:

• Der Beleg enthält mehrere Transaktionen, die als eine einzige Transaktion eingegeben wurden. Hier sind einige mögliche Beispiele:

  • Mehrere Kreditorenzahlungen werden in jeder Zeile eingegeben (es wird kein Gegenkonto verwendet), und die Zahlungssumme, die einem Bankkonto gegenübergestellt wird, wird in einer Zeile eingegeben. Die Zahlungszusammenfassung wird durchgeführt, um das Untersachkonto der Bank als zusammengefassten Betrag zu aktualisieren, der mit dem Bankkontoauszug übereinstimmt. Jede Kreditorentransaktion wird jedoch weiterhin detailliert im Untersachkonto des Kreditorenkontos erfasst. Dasselbe Szenario findet sich auch auf der Debitorenzahlungsseite.
  • Mehrere Anlagen werden in einem einzigen Beleg erworben. Dieser Ansatz wird häufig verwendet, wenn Anfangssalden für das Modul Anlagen eingegeben werden.

• Der Beleg enthält eine Transaktion, die sich auf mehrere Nicht-Sachkontotypen auswirkt. Hier sind einige mögliche Beispiele:

  • Bestandsüberweisungen
  • Verrechnung von Kreditoren-/Debitorensalden (gleiche Partei)
  • Übertragen von Salden von Debitor A auf Debitor B
  • Kreditorenrechnungen mit mehreren Positionen, die Anlagen oder Projekte enthalten

Die vorangegangenen Beispiele für jede Kategorie stellen gültige Geschäftsanforderungen dar. Manchmal können die geschäftlichen Anforderungen nicht anders erfüllt werden: Die Organisation muss die Transaktionen als „Ein Beleg“ eingeben. Zu anderen Zeiten gibt es jedoch andere gültige Möglichkeiten, die Geschäftsanforderungen zu erfüllen: Die Transaktionen können anders eingegeben werden oder es kann eine andere Funktion verwendet werden.

Abgänge mit einem Beleg

Die Verwendung der „Ein Beleg“-Funktion zur Erfüllung geschäftlicher Anforderungen kann zu Problemen führen. Verschiedene Prozesse, Transaktionsstornierungen und Anfragen/Berichte erfordern Transaktionsdetails. Diese Details können aus dem aktuellen Datenmodell nicht ermittelt werden, wenn mehrere Transaktionen zusammengefasst in einem einzigen Beleg erfasst werden. Außerdem können die Details nicht immer eindeutig bestimmt werden, wenn der eingegebene Transaktionstyp unbekannt ist. Diese Einschränkung wird durch die Flexibilität von Erfassungen verursacht, insbesondere wenn sie über die allgemeine Erfassungen erneut eingegeben werden.

Einige Szenarien funktionieren je nach Einrichtung Ihrer Organisation möglicherweise weiterhin ordnungsgemäß. In folgenden Bereichen können Probleme auftreten:

• Ausgleich – Wenn mehr als ein Kreditor oder Debitor auf einem Beleg vorhanden ist, wird die während der Abrechnung erstellte Buchhaltung möglicherweise fälschlicherweise Finanzdimensionen zugewiesen. Weitere Informationen zu Problemen, die während des Ausgleichs auftreten können, finden Sie unter Einzelnen Beleg mit mehreren Debitoren- oder Kreditorendatensätzen.

• Steuerberechnung – Wenn mehr als ein Beleg oder Debitor auf einem Beleg vorhanden ist, ist die Steuerberechnung möglicherweise falsch.

• Transaktionsstornierung – Wenn mehr als ein Untersachkontotyp auf einem Beleg vorhanden ist, wird bei der Stornierung einer einzelnen Untersachkontotransaktion möglicherweise ein falscher Buchhaltungseintrag für die Stornierung im Hauptbuch gebucht. Wenn Sie beispielsweise mehrere Anlagen in einem einzigen Beleg erwerben und dann den Erwerb einer der Anlagen stornieren, wird die Buchhaltung im Hauptbuch für die Stornierung nicht korrekt sein.

• Berichterstellung und Anfragen – Wenn Sie mehr als einen Untersachkontotyp (z. B. Kreditor und Debitor) auf einem Beleg angeben, zeigen Berichte/Anfragen nur den ersten gefundenen Kontowert an.

  Angenommen, Sie haben die folgende mehrzeilige Kreditorenrechnung. Sie enthält vier Projekte, die die „Positionen“ auf der Rechnung darstellen. Dieser Ansatz ist eine gängige Geschäftsanforderung für Organisationen, die Erfassungen intensiv nutzen.

  

  Drei der vier Projekte werden auf dasselbe Hauptkonto (601500) gebucht. Wenn Sie den Buchhaltungsquellen-Explorer öffnen, um Details zu gebuchten Transaktionen für dieses Hauptkonto anzuzeigen, werden Sie feststellen, dass die Projekt-ID für alle drei Positionen 000057 ist. Dieses Verhalten ist eine bekannte Einschränkung von „Ein Beleg“. Die Details verknüpfen nicht jede Position korrekt mit dem entsprechenden Projekt in der Erfassung. Stattdessen wird in Berichten und Anfragen immer der erste gefundene Kontowert angezeigt.

  

Transaktion als „Ein Beleg“ eingeben

Um Transaktionen als „Ein Beleg“ einzugeben, gehen Sie zu Hauptbuch > Sachkonto einrichten > Hauptbuchparameter, und legen Sie dann auf der Registerkarte Hauptbuch die Option Mehrere Transaktionen innerhalb eines Belegs zulassen auf Ja fest.

Sie können eine Transaktion mit einem Beleg auf der Seite Erfassungsnamen eingeben, indem Sie das Feld Neuer Beleg auf einen der folgenden Werte festlegen:

• Nur eine Belegnummer – Jede Position, die Sie der Erfassung hinzufügen, wird in denselben Beleg aufgenommen, und die Positionen enthalten mehr als einen Debitor, einen Kreditor, eine Bank, eine Anlage oder ein Projekt.
• Im Zusammenhang mit Ausgleich – Geben Sie einen mehrzeiligen Beleg ein, bei dem es kein Gegenkonto gibt und die Zeilen mehr als einen Debitor, Kreditor, eine Bank, Anlage oder ein Projekt enthalten.
• Im Zusammenhang mit Ausgleich – Geben Sie einen einzeiligen Beleg ein, bei dem das Konto und das Gegenkonto eine Kontenart für untergeordnete Sachkonten enthält, beispielsweise Kreditor/Kreditor, Debitor/Debitor, Kreditor/Debitor oder Bank/Bank.

Ist für mein Geschäftsszenario ein Beleg erforderlich?

Die folgenden Geschäftsszenarien wurden als Szenarien identifiziert, für die Debitoren die Funktionalität „Ein Beleg“ verwenden. Einige Geschäftsanforderungen können nur mithilfe von „Ein Beleg“ erfüllt werden. Für viele andere sind jedoch Alternativen verfügbar.

Szenario	Description	Ein Beleg erforderlich?	Alternativ
Zusammenfassung der Kreditorenzahlung	Eine Organisation übermittelt eine Liste von Kreditoren und Beträgen an ihre Bank. Die Bank verwendet diese Liste, um die Kreditoren im Namen der Organisation zu bezahlen. Jede Kreditorenzahlung muss detailliert in den Kreditorenkonten gebucht werden, aber die Summe der Zahlungen wird als einzelne Auszahlung auf dem Bankkonto gebucht.	Nr.	Ab Microsoft Dynamics 365 Finance Version 10.0.32 gibt es eine Funktion mit dem Namen Möglichkeit zum Buchen ausführlicher Kreditoren- und Debitorenzahlungen mit zusammengefassten Beträgen im Bankkonto. Weitere Informationen finden Sie unter Ausführliche Kreditoren- und Debitorenzahlungen buchen.
Zusammenfassung der Debitorenzahlung	Debitorenzahlungen werden pauschal auf dem Bankkonto hinterlegt. Jede Debitorenzahlung muss detailliert in den Debitorenkonten gebucht werden, aber die Summe der Zahlungen wird als einzelne Einzahlung auf dem Bankkonto gebucht.	Nr.	Ab Dynamics 365 Finance Version 10.0.32 gibt es eine Funktion mit dem Namen Möglichkeit zum Buchen ausführlicher Kreditoren- und Debitorenzahlungen mit zusammengefassten Beträgen im Bankkonto. Weitere Informationen finden Sie unter Ausführliche Kreditoren- und Debitorenzahlungen buchen.
Debitoren-/Kreditorenrechnung	Eine Rechnung wird für einen einzelnen Debitor oder Kreditor eingegeben, aber zusätzliche Positionen stellen die Positionen der Rechnung dar und haben mehrere Anlagen oder Projekte.	Ja
Debitorenvorauszahlungszahlungserfassung, die Steuern auf mehreren " Positionen" anzeigen	Ein Debitor leistet eine Vorauszahlung für eine Bestellung. Die Positionen der Bestellung haben unterschiedliche Steuern. Die Vorauszahlung des Debitors muss den Debitor in mehreren Positionen enthalten, damit die Steuern für jede Position berechnet werden können.	Ja
Debitor-Rückerstattung	Wenn die periodische Aufgabe die Preiserstattung vom Debitorenkonto ausgeführt wird, erstellt sie eine Buchung, um den Saldo von einem Debitor zu einem Kreditor zu verschieben. Der Kreditor ist dieselbe Partei wie der Debitor.	Ja
Erhaltung des Anlagenbestandes: Ausgleichsabschreibung, Aufteilung einer Anlage und Berechnung der Abschreibung für Abgang	Ausgleichsabschreibung, Aufteilung einer Anlage und Berechnung der Abschreibung für den Abgang von Anlagen, die alle zur Erstellung eines einzigen Belegs verwendet werden.	Nr.	Ab Finance Version 10.0.21 verwenden Buchungen für Anlagen, die zum Nachholen der Abschreibung, zum Aufteilen einer Anlage und zum Berechnen der Abschreibung für den Abgang einer Anlage erstellt werden, unterschiedliche Belegnummern.
Wechsel und Solawechsel	Wechsel und Solawechsel verschieben den Debitoren- bzw. Kreditorensaldo von einem Debitoren- oder Kreditorensachkonto auf ein anderes, basierend auf dem Status der Zahlung. Da im Beleg immer derselbe Debitor oder Kreditor verwendet wird, gibt es keine Berichtsprobleme.	Ja
Saldierung	Wenn ein Debitor und ein Kreditor zur selben Partei gehören, werden die Salden für den Kreditor und den Debitor miteinander verrechnet. Durch diesen Ansatz wird der Geldwechsel zwischen einer Organisation und der Debitoren-/Kreditorenpartei minimiert.	Nein	Ab Microsoft Dynamics 365 Finance Version 10.0.40 gibt es die Funktion Kunden- und Lieferanten-Netting . Durch die Netting-Funktion werden automatisch zwei separate Belege für Lieferant und Kunde erstellt. Weitere Informationen finden Sie unter Nettolieferanten- und -kundensalden.
Salden übertragen	Eine Organisation muss ggf. ein Saldo von einem Kreditor an einen anderen übertragen, entweder aufgrund eines Fehlers oder weil ein anderer Kreditor die Verbindlichkeiten übernommen hat. Übertragungen dieses Typs treten auch bei Kontentypen auf, wie beispielsweise Debitoren und Bank.	Ja/Nein	Saldo-Übertragungen von einem Konto (Kreditor, Debitor, Bankkonto, usw.) in ein anderes können von separaten Belegen ausgeführt werden, und das Gegenkonto kann auf ein Sachkonto gebucht werden. Für einige Organisationen erfordert dieser Ansatz zu viele Gemeinkosten. Daher entscheiden sie sich stattdessen für einen Beleg.
Nicht gebuchte Zahlungen mit der gleichen Rechnung ausgleichen	Dieses Szenario findet sich in der Regel in Organisationen, in denen Kunden mehrere Zahlungsmethoden zur Bezahlung von Einkäufen verwenden können. In diesem Szenario muss die Organisation in der Lage sein, mehrere nicht gebuchte Zahlungen zu erfassen und mit der Debitorenrechnung auszugleichen.	Nr.	Eine neue Fähigkeit, die in Finance hinzugefügt wurde, ermöglicht es, dass mehrfach nicht gebuchte Zahlungen nicht mit einzelnen Rechnungen ausgeglichen werden.
Landes-/regionsspezifische Funktionen	Die Funktion Einheitspapier der Versandanmeldung (Single Administrative Document, SAD) für Polen erfordert derzeit, dass Transaktionen gruppiert werden, und zu diesem Zweck wird die Belegnummer verwendet. Es gibt möglicherweise zusätzliche länder-/regionsspezifische Funktionen, die die „Ein Beleg“-Funktionalität benötigen.	Ja
Mechanismus, um Buchungen über ein Geschäftsereignis zu gruppieren	Eine Organisation hat ein einzelnes Geschäftsereignis, das mehrere Transaktionen auslöst. Die Buchhaltung möchte die Buchhaltungseinträge zur besseren Überprüfung zusammen anzeigen. Ein ähnliches Szenario ist eines, in dem Banktransaktionen in Finance über eine Datei erfasst werden, die von der Bank empfangen wird. Organisationen möchten diese Transaktionen gruppieren, indem die Bankauszugsnummer in der Datei verwendet wird.	Nr.	Obwohl das Gruppieren von Transaktionen ein gültiges Szenario ist, darf die Belegnummer niemals für diesen Zweck verwendet werden. Belege stellen immer einzelne Transaktionen dar, niemals eine Gruppe von Transaktionen. Transaktionen können stattdessen anhand anderer Felder gruppiert werden, wie beispielsweise der Erfassungschargennummer selbst oder der Dokumentnummer.
Eingeben von Anfangssalden	Organisationen geben häufig die Anfangssalden für Konten für untergeordnete Sachkonten (Debitoren, Kreditoren, Anlagen, usw.) als eine einzelne Belegbuchung ein.	Nr.	Anfangssalden für jedes Untersachkonto müssen als separate Belege eingegeben werden. Der Ausgleich kann auf ein Verrechnungssachkonto gebucht werden, das mit dem Anfangssaldo für das Hauptbuch verrechnet wird.
Korrigieren des Buchhaltungseintrags eines gebuchten Dokuments	Eine Organisation muss möglicherweise das Debitoren- oder Kreditorensachkonto für eine gebuchte Rechnung korrigieren. Da die Rechnung korrekt ist, sollte sie nicht storniert werden.	Ja/Nein	Wenn eine Korrektur des Debitor- oder Kreditorsachkontos vorgenommen wird, kann eine Regulierung auf das Sachkonto vorgenommen werden. Dieser Ansatz erfordert, dass die Regulierung während einer „Ausfallzeit“ vorgenommen wird, damit das Sachkonto vorübergehend die manuelle Eingabe zulassen kann. Ein Nachteil dieses Ansatzes besteht darin, dass die Kreditoren-/Debitoren-zu-Hauptbuch-Abstimmungsberichte eine Differenz beim Ein- und Ausgang zeigen. Der Nettobetrag ist 0 (Null).
Buchung in Zusammenfassung im Hauptbuch	Organisationen möchten häufig im Hauptbuch als Zusammenfassung buchen, um die angezeigte Datenmenge zu verringern. Allerdings verlangen die Organisationen in der Regel, dass die Buchungsdetails beibehalten werden. Wenn das Buchen zusammenfassend mit einem einzelnen Beleg erfolgt, sind die Buchungsdetails nicht bekannt und können nicht verwaltet werden.	Nr.	Da die Buchungsdetails nicht vorhanden sind, dürfen Organisationen „Ein Beleg“ nicht verwenden, um in der Zusammenfassung zu buchen, wenn die Details für die Berichterstellung erforderlich sind
"Das System erlaubt es"	Organisationen verwenden häufig nur eine Belegfunktionen, da sie das System verwenden können, ohne die Auswirkungen zu veranschaulichen.	Nr.	Die bloße Tatsache, dass das System die Nutzung der Funktionalität ermöglicht, ist niemals ein triftiger Grund. Die Funktionalität sollte nur verwendet werden, wenn sie zur Erfüllung einer anderen Geschäftsanforderung erforderlich ist.

Die Zukunft von „Ein Beleg”

Aufgrund der Probleme, die bei der Verwendung eines Belegs auftreten können, werden die folgenden Optionen untersucht:

• Neue Funktionen werden weiterhin eingeführt, wenn es einen besseren Weg gibt, ein Geschäftsszenario zu verwirklichen. Beispielsweise ermöglicht eine in der Finance-Version 10.0.32 eingeführte Funktion, dass Zahlungen zwar als separate Belege erfasst werden, das Bankkonto aber trotzdem zusammenfassend aktualisiert wird. Wenn Funktionen hinzugefügt werden, werden sie für jedes Geschäftsszenario in der Spalte „Alternative“ der vorhergehenden Tabelle dokumentiert.
• Einige Transaktionen werden möglicherweise weiterhin über die Erfassung in einem einzigen Beleg eingegeben, es können jedoch zusätzliche Daten nachverfolgt werden, um Transaktionsdetails korrekt zu identifizieren.
• Es könnte eine Kombination neuer Funktionen verwendet werden, aber Transaktionen für die Geschäftsszenarien könnten weiterhin unter Verwendung eines einzigen Belegs in die Erfassung eingegeben werden.

Wenn neue Funktionen eingeführt werden, muss Ihre Organisation fortlaufend prüfen, ob die Option Mehrere Transaktionen innerhalb eines Belegs zulassen auf der Seite Hauptbuchparameter abgeschaltet werden kann. Wir empfehlen, dass Sie „Ein Beleg“ nicht für Integrationen verwenden, sofern Sie die Funktionalität nicht für die dokumentierten Funktionslücken benötigen.

Sobald Funktionslücken geschlossen sind, wird Microsoft die neuen Funktionen bekannt geben, die anstelle von One Voucher verwendet werden können. In manchen Geschäftsszenarien, z. B. bei einer Lieferantenrechnung mit mehreren Zeilen, wird weiterhin ein Beleg verwendet, allerdings mit Erweiterungen. Diese Verbesserungen werden mitgeteilt, sobald sie verfügbar sind.