Informationen zu Unterschieden bei der Abstimmung des Hauptbuchs mit der Kreditorenverwaltung oder dem Debitorenmanagement

In diesem Artikel wird erläutert, warum sich der Kontostand der Kreditorenkonten oder der Debitorenkontossaldo im Hauptbuch von dem Gesamtbetrag unterscheidet, der im Bericht "Historisches Veraltetes Testguthaben" in Microsoft Dynamics GP fällig ist. Am Ende dieses Artikels werden häufig gestellte Fragen gestellt.

Gilt für: Microsoft Dynamics GP
Ursprüngliche KB-Nummer: 866570

Die Routine "Mit GL abstimmen" war neu in Microsoft Dynamics GP 10.0 (SP2). Diese Routine generiert ein Microsoft Office Excel-Arbeitsblatt. Sie können dieses Arbeitsblatt verwenden, um Transaktionen in der Kreditorenverwaltung oder debitorenverwaltung abzugleichen, die im Hauptbuch gebucht wurden. Dieser Prozess generiert keine korrigierenden Transaktionen. Dieser Prozess kann Ihnen jedoch helfen, die in diesem Abschnitt aufgeführten Transaktionsunterschiede zu ermitteln. Um das Fenster Mit GL abstimmen zu öffnen, zeigen Sie im Menü Microsoft Dynamics GP auf Tools, zeigen Sie auf Routinen, zeigen Sie auf Finanzen, und wählen Sie dann Mit GL abstimmen aus.

Im Folgenden finden Sie eine Liste ausgeführter Probleme, die aufgetreten sind und unterschiede verursachen können:

• Nicht alle GL-Batches werden gebucht. (Das Arbeitsblatt "Mit GL abstimmen" meldet nur gebuchte Einträge.)

• Der Bericht "Historisches Veraltetes Testguthaben" wird mit Einschränkungen gedruckt. Drucken Sie den Bericht "Historisches Veraltetes Testguthaben" erneut mit nur einer Datumseinschränkung aus.

• Nicht alle Kreditorenkonten oder alle Debitorenkonten werden im Hauptbuch angezeigt. Stellen Sie sicher, dass Sie alle Kreditorenkonten oder alle Debitorenkonten im Hauptbuch anzeigen.

• Batches in der Kreditorenverwaltung oder im Debitorenmanagement wurden im Hauptbuch gebucht. Der Batch im Hauptbuch wurde vor der Veröffentlichung geändert oder bearbeitet.

• Anpassungen des Kreditorenkontos oder des Debitorenkontos können direkt im Hauptbuch erfasst worden sein. Diese Transaktionen aktualisieren das Konto im Hauptbuch. Diese Transaktionen aktualisieren jedoch nicht den Bericht über veraltete Testversionen.

• Der Datumsbereich im Detaillierten Testsaldobericht im Hauptbuch stimmt nicht mit dem Datumsbereich im Bericht "Historisches Veraltetes Testguthaben" in der Kreditorenverwaltung oder im Debitorenmanagement überein. Aktivieren Sie beim Drucken des Berichts Veraltetes Testguthaben im Bereich Select Transactions For Report Using das Kontrollkästchen GL-Buchungsdatum.

• Transaktionen wurden im Kreditorenmanagement oder im Debitorenmanagement gebucht. Diese Transaktionen wurden jedoch nicht im Hauptbuch gebucht, wenn es sich um Anfangssalden handelte. Wenn das Kontrollkästchen In Hauptbuch buchen im Fenster Buchung einrichten für die Reihe "Einkauf" oder für die Reihe "Sales" nicht aktiviert ist, werden die Transaktionen an die Kreditorenverwaltung oder die Debitorenverwaltung gebucht. Diese Transaktionen werden jedoch nicht im Hauptbuch gebucht.

• Das Kontrollkästchen Rabatte nachverfolgen, die in GL verfügbar sind, ist im Fenster "Kreditorenverwaltung einrichten" oder im Fenster "Debitorenverwaltung einrichten" aktiviert. Anschließend wird der Nettobetrag der Rechnung in das Hauptbuch gebucht. Darüber hinaus wird der verbleibende Betrag auf ein verfügbares Rabattkonto gebucht. Nur der Nettobetrag wird im Detaillierten Testsaldobericht im Hauptbuch angezeigt. Die Rechnung zeigt jedoch den Bruttorechnungsbetrag für den historischen veralteten Testsaldo in der Kreditorenverwaltung oder im Debitorenmanagement an.

• Dokumente wurden in einem anderen Zeitraum als ursprünglich veröffentlicht. Der detaillierte Testsaldobericht im Hauptbuch entspricht möglicherweise nicht dem Bericht "Verlauf veralteter Testversionen". Angenommen, eine Rechnung wurde am 01.01.2007 eingegeben. Diese Rechnung wurde am 01.02.2007 für ungültig erklärt. Für den 01.02.2007 - 28.02.2007 wird ein detaillierter Bericht zur Testbilanz des Hauptbuchs ausgegeben. Die ungültige Transaktion wird im Bericht angezeigt. Wenn ein veraltetes Testguthaben mit demselben Datumsbereich gedruckt wird, wird das ungültige Dokument nicht auf dem Bericht gedruckt, da es für ungültig erklärt wurde.

• Wenn Sie den Kreditorensaldo oder den Debitorenkontosaldo im Hauptbuch für einen bestimmten Zeitraum in den Bericht "Historisches Veraltetes Testguthaben" abgleichen möchten, müssen die Salden aus dem Bericht "Historisches Veraltetes Testguthaben" mit der Nettoänderung des detaillierten Testguthabens im Hauptbuch für den gleichen Zeitraum abgeglichen werden.

• Wenn Sie den Kreditorensaldo oder den Debitorenkontosaldo im Hauptbuch für einen Tag, der nicht in einem bestimmten Zeitraum liegt, in den Bericht "Historisches Veraltetes Testguthaben" abgleichen möchten, bestimmen Sie, ob das Kreditorenmanagement oder das Debitorenmanagement jemals ausgeglichen wurde. Wenn das Kreditoren- oder Forderungsmanagement noch nie ausgeglichen wurde, sind die Anfangssalden möglicherweise falsch. In dieser Situation sollten Sie zuerst den aktuellen Zeitraum ausgleichen und dann die vorherigen Monate in umgekehrter Reihenfolge abgleichen.

• Wenn Buchungsunterbrechungen aufgetreten sind, wurden Batches möglicherweise nicht ordnungsgemäß im Hauptbuch, in der Kreditorenverwaltung oder in der Debitorenverwaltung gebucht.

• Beim Drucken des Berichts Veraltetes Testguthaben haben Sie im Bereich Ausschließen nicht die folgenden Kontrollkästchen ausgewählt.

• Aktivieren Sie diese Kontrollkästchen, und drucken Sie dann den Bericht Historisches Veraltetes Testguthaben aus.

  Hinweis

  Deaktivieren Sie das Kontrollkästchen Vollständig bezahlte Dokumente , wenn Sie den Bericht "General Ledger Detailed Trial Balance" und den Bericht "Verlauf veralteter Testguthaben" nach bestimmten Dokumenten abgleichen möchten.

  • Nicht gepostete angewendete Gutschriftdokumente
  • Nullsaldo
  • Aktivität

• Wenn Sie die Multicurrency-Verwaltung bei der Neuauswertung verwenden, haben Sie die Bereitstellung im Einkaufs-/Verkaufsoffsetkonto ausgewählt.

• Guthaben Karte Beträge, die im Fenster "Kreditorentransaktionseintrag" für eine Rechnung eingegeben wurden. Dies kann zu einem Ungleichgewicht bei der Abstimmung zwischen der Kreditorenverwaltung und dem Hauptbuch führen, da nur die Nettoänderung in das Hauptbuchmodul erfolgt. (Das heißt, es scheint, als ob GL-Transaktionen fehlen, aber die Beträge auf der GL-Seite werden in einem GL-Eintrag zusammengefasst, während die PM-Seite drei Datensätze enthalten kann. Sie sollten jedoch in späteren Versionen weiterhin übereinstimmen und ordnungsgemäß zum Abschnitt Übereinstimmende Transaktionen wechseln.)

• Wenn es Buchungsunterbrechungen/Probleme mit einem Kreditoren- oder Forderungsbatch gab und die Transaktionen gleichzeitig in den Tabellen Work und Open gefunden wurden, führt das Löschen des RM- oder PM-Batches in Microsoft Dynamics GP zu Problemen. In diesem instance sieht der Benutzer in der Regel die Datensätze in beiden Tabellen und entscheidet, dass er den Arbeitsbatch nicht benötigt, sodass er ihn einfach in Microsoft Dynamics GP löscht. Da die Tabellen Work und Open eine Verteilungstabelle gemeinsam nutzen, werden beim Löschen des Batches in Microsoft Dynamics GP auch die Verteilungsdatensätze entfernt. Das Endergebnis ist, dass der Transaktionsheaderdatensatz vorhanden ist, aber keine übereinstimmenden Verteilungen auf der RM- oder PM-Seite vorhanden sind, aber GL wurde ordnungsgemäß aktualisiert. Dieses Problem wird in der nächsten Version von Microsoft Dynamics GP berücksichtigt.

• Verteilungen werden möglicherweise im Abschnitt Potenziell übereinstimmend mit unterschiedlichen Beträgen angezeigt, wenn Rabatte vorhanden sind. Um eine Übereinstimmung zu erhalten, sollten die Rabatt-GL-Konten mit dem PM/RM-Konto abgerufen worden sein, bevor der Prozess "Abgleichen mit GL" ausgeführt wird. Schließen Sie das Arbeitsblatt, und führen Sie sie mit den aufgeführten GL-Rabattkonten erneut aus.

• Verteilungen können auf der PM/RM-Seite fehlen, wenn der Typ (CASH, PAY, PURCH) geändert wurde. In der Abgleichstabelle wird das Konto nur für die GL-Seite verwendet. Das Konto wird auf der PM/RM-Seite nicht verwendet. Die PM/RM-Seite verwendet den Typ PAY oder REC, unabhängig davon, welches Konto verwendet wird. Daher sollten Sie unbedingt alle Ihre AP- oder AR-Konten im Abstimmungsfenster auflisten. Durch das einfache Wechseln des Verteilungstyps in der SQL-Tabelle wird die Verteilung nicht automatisch angezeigt, wenn Sie das Arbeitsblatt erneut generieren. (Dies war in früheren Versionen ein Problem für Guthaben Karte Zahlungen, die den Cash-Typ verwenden und das AP-Konto getroffen haben, aber diese Datensätze werden in GP 2016 angezeigt, sodass kein Problem mehr zu sein scheint.)

• Überprüfen Sie das Anwendungsdatum und das GL-Postdatum in der Apply-Tabelle für Multicurrency-Transaktionen im Vergleich zu dem tatsächlichen Datum, an dem sie in GL gebucht wurden. Beispielsweise wurde am 22. Januar eine Gutschrift vom 31. Dezember auf eine Rechnung vom 5. Dezember angewendet, und das Anwendungsdatum und das GL-Postdatum wurden als 22. Januar belassen. Beim Veröffentlichen des GL-Batches änderte der Benutzer das Datum jedoch in den 31. Dezember. In diesem Fall listet die Tabelle Mit GL abstimmen für den Monat Dezember den realisierten Gewinn-/Verlustbetrag auf beiden Seiten auf, und sie scheinen abgestimmt zu sein. Der HATB-Bericht erkennt jedoch noch nicht den realisierten Gewinn-/Verlustbetrag an und wird im Vergleich zu GL um diesen Betrag abgesetzt, da er nicht bis Januar gemäß dem angewendeten Datensatz angewendet oder gebucht wurde.  

Häufig gestellte Fragen

F1: Ist die Tabelle "Mit GL abstimmen" eine echte Abstimmung für Kreditoren/Forderungen an GL?

A1: Das Feature "Abstimmung mit GL" ist ein Tool zur Problembehandlung , mit dem Benutzer nicht übereinstimmende Verteilungen zwischen RM/PM und GL identifizieren können. Es war nicht unbedingt dazu gedacht, sich an die HATB zu binden, und das war nicht der beabsichtigte Zweck, obwohl wir wissen, dass kunden dies tun. Die Salden in der Tabelle Mit GL abstimmen sind die besten Schätzungen, die eine einfache Addition/Subtraktion für die Verteilungen in der Tabelle verwenden. Während die Salden auf dem HATB fast jede Tabelle berücksichtigen und viel komplexer und genauere Salden sind, sind die beiden oft nicht miteinander verbunden.

Die richtige Abstimmung sollte zwischen dem RM- oder PM Historical Aged Trial Balance -Bericht (HATB) und den GL-Testbilanzberichten erfolgen. Wenn diese übereinstimmen, müssen Sie nicht unbedingt das Tool Abgleichen mit GL für diesen Monat ausführen. Die GL-Tabellen bestehen aus Lastschriften und Gutschriften, und die Tabellen, aus denen der HATB abruft, sind Transaktionsheader und anwenden Datensatztabellen. Kunden fragten also nach einer Möglichkeit, die Verteilungen in GL mit den Verteilungstabellen in RM oder PM abzugleichen, um Unterschiede auf dieser Ebene zu finden. Dies ist der Grund, warum die Routine "Reconcile to GL" erstellt wurde. Es sollte ein Tool zur Problembehandlung sein, um Verteilungen mit Verteilungen zwischen den Modulen zu vergleichen, um fehlende Verteilungen zu identifizieren, was Sie möglicherweise zu einer fehlenden Transaktion aus dem HATB zurückführen kann. Verwenden Sie daher das Tool "Mit GL abstimmen" nur als Hilfe , um das HATB-Mit-GL-Testguthaben zu vereinbaren. Wenn die HATB- und GL-TB-Balance besteht, ist es nicht wirklich erforderlich, das Tool Abgleichen mit GL für diesen Monat auszuführen.

F2: Sollten die Summen in der Tabelle "Mit GL abstimmen" mit den Summen auf dem HATB übereinstimmen?

A2: Nein. Die Summen in der Tabelle Mit GL abstimmen sind nur eine einfache Addition/Subtraktion der Verteilungsdatensätze in dieser Tabelle und berücksichtigen keine anderen Tabellen. Während der HATB völlig andere Tabellen untersucht, um einen Saldo mithilfe der Transaktion zu berechnen und Datensatztabellen anzuwenden, ist dies eine wesentlich komplexere Berechnung. Aufgrund der verschiedenen Berechnungsmethoden/Tabellen, die zum Abrufen der Salden verwendet werden, wird erwartet, dass die Tabelle Abgleichen mit GL nicht direkt mit den alternden Salden in den HATB-Berichten verknüpft ist, und würde deren Abstimmung erschweren. Es ist nicht erforderlich, die Salden in der Tabelle "Abgleich mit GL" mit dem HATB-Bericht zu verknüpfen.

Wir empfehlen, die Summen in der Tabelle "Abgleich mit GL" zu ignorieren und einfach die Abschnitte "Nicht übereinstimmend" und "Potenziell übereinstimmend" zu verwenden, um Unterschiede bei der Recherche zu ermitteln, um festzustellen, ob dies auch einen Unterschied zwischen GL TB und HATB erklären kann. Die Abgleichstabelle mit GL ist keine echte Abstimmung und sollte nur als Hilfe dienen, um Verteilungsunterschiede zu ermitteln, um festzustellen, ob dies auch auf Transaktionsebene ein Unterschied ist. Wenn der HATB mit der GL-TB übereinstimmt, müsste das Hilfsprogramm "Abgleich mit GL" für diesen Monat überhaupt nicht ausgeführt werden, da es keine Unterschiede gibt, die identifiziert werden müssen.

Wenn Sie das Guthaben für die Abgleichstabelle mit GL weiterhin an das Guthaben auf dem HATB binden möchten, wird dies in einem regulären Supportfall nicht unterstützt. Die Gründe, die wir identifiziert haben, sind oben in dieser KB aufgeführt, und es könnten weitere Gründe noch nicht identifiziert werden. Da diese Abstimmung jedoch nicht notwendig ist zwischen dem einfachen Gesamtsaldo, der in der Tabelle "Abgleich mit GL" aufgeführt ist, und dem komplexeren berechneten Saldo im HATB-Bericht und nicht dem beabsichtigten Zweck dieses Abgleichshilfsprogramms, würde es als Beratungsaufwand angesehen werden, ihre Daten zu untersuchen, um Ihnen zu helfen, diese miteinander abzugleichen.

F3: Was soll ich tun, wenn Verteilungen auf der GL-Seite fehlen?

A3: Wenn Sie Verteilungen auf der RM- oder PM-Seite finden, die sich nicht auf der GL-Seite befinden, untersuchen Sie die GL-Seite auf Zeitliche Unterschiede. Stellen Sie sicher, dass alle GL-Batches gebucht werden. Wenn sie auf der GL-Seite wirklich fehlen, müssen Sie einen Anpassungsjournaleintrag direkt in GL eingeben, damit der Eintrag die GL-Verteilungen erstellen kann.

F4: Was soll ich tun, wenn Verteilungen auf rm- oder PM-Seite fehlen?

A4: Wenn die GL-Verteilung aufgeführt ist, aber auf der RM- oder PM-Seite fehlt, untersuchen Sie zunächst die Zeitlichen Unterschiede. Recherchieren Sie auch, ob die Transaktion selbst im HATB-Bericht aufgeführt ist und bereits berücksichtigt wird. Es ist möglich, dass die Transaktion vorhanden ist, aber die Verteilungen fehlen einfach. Die Frage stellt sich also , wie erhalte ich dann die Verteilungen in RM oder PM, wenn die Transaktion vorhanden ist? Beachten Sie zunächst, dass die Verteilungstabellen in RM oder PM nicht für andere Zwecke oder Berichte in GP verwendet werden, außer für diese Abstimmungstabelle. Ist es also wirklich notwendig, sie wieder in RM oder PM hinzuzufügen? Bewerten Sie, ob es sich lohnt, eine Tabelle aufzufüllen, die nirgendwo anders verwendet wird.

Wenn Sie sich jedoch dafür entscheiden, die PM-Verteilungstabelle zu korrigieren, müssten Sie das Dokument für ungültig erklären, sodass die angewendeten Datensätze wieder geöffnet werden. Verwenden Sie dann das Hilfsprogramm zum Entfernen des Transaktionsverlaufs, um das ungültige Dokument zu entfernen. Stellen Sie sicher, dass die Veröffentlichung auf Post an GL und nicht auf GL eingestellt wird. Löschen Sie den von void erstellten GL-Batch. Erstellen Sie das Dokument dann wieder in die Kreditoren ein, damit die Transaktionen und Verteilungen neu erstellt werden. Stellen Sie sicher, dass Sie den GL-Batch dafür ungültig machen. Dann das neue Dokument erneut auf die geöffneten Dokumente anwenden, und sie sollten erneut in den Verlauf verschoben werden.

Um dies in der RM-Verteilungstabelle zu beheben, müssten Sie beide Seiten der Rechnung und der Zahlung entfernen und beide erneut schlüsseln und den Batch in GL löschen.

F5: Die Transaktionen im Abschnitt Potenziell übereinstimmend sehen so aus, als wären sie übereinstimmend. Warum befinden sie sich nicht im Abschnitt Übereinstimmend?

A5: Es gibt mehrere Felder, die für jeden Verteilungsdatensatz abgeglichen werden. Alle Felder müssen übereinstimmen, um sie in den Abschnitt Übereinstimmend zu verschieben. Wenn einige, aber nicht alle Felder übereinstimmen, wird sie im Abschnitt Potenziell übereinstimmend abgelegt. Hier sind beispielsweise die Felder aufgeführt, die für PM mit GL abgeglichen werden:

Kreditorenverwaltung -- GL
Gutscheinnummer - Ursprungskontrollnummer
TRX-Quelle : Ursprüngliche TRX-Quelle
Buchungsdatum -- Transaktionsdatum
On Account Amount -- Debit Amount oder Credit Amount

F6: Wenn ich die fehlenden Verteilungen in GL oder RM/PM beschlüssele und die Tabelle Mit GL abstimmen erneut ausführen, werden dann die nicht übereinstimmenden oder möglicherweise übereinstimmenden Elemente in den Abschnitt Übereinstimmend verschoben?

A6: Nein. Wenn die Transaktionen separat geschlüsselt werden, weist unterschiedliche Gutscheinnummern und Trx-Quellcodes auf. Bestenfalls stimmen buchungsdatum und -beträge überein, sodass sie im Abschnitt Potenziell übereinstimmend der Kalkulationstabelle platziert werden könnten.

F7: Warum stimmt das Endguthaben einer monatlichen oder vierteljährlichen Kalkulationstabelle nicht mit dem Anfangssaldo der nächsten monatlichen oder vierteljährlichen Kalkulationstabelle überein?

A7: Wenn der Endsaldo eines Zeitraums nicht mit dem Anfangssaldo des nächsten Zeitraums übereinstimmt, liegt dies häufig an verwaisten Verteilungsdatensätzen, denen in der Unterbuchtabelle kein Headerdatensatz zugeordnet ist. Der Endsaldo wird von Excel direkt in der Kalkulationstabelle berechnet. Es wird lediglich der Anfangssaldo für diesen Zeitraum oben in der Kalkulationstabelle verwendet und die Verteilungsdatensätze, die in der Kalkulationstabelle angezeigt werden, addiert/subtrahiert, um den Endsaldo zu erreichen. Auf der anderen Seite wird im nächsten Zeitraum der Anfangssaldo berechnet, indem eine einfache Last-/Gutschriftberechnung der Verteilungsdatensätze in der SQL-Tabelle verwendet wird, und die gespeicherte Prozedur verknüpft die Headertabelle, sodass sie keine Verteilungen enthält, für die ein Headerdatensatz fehlt. Das Endergebnis könnte sein, dass einige Verteilungen in den Endsaldo der vorherigen Kalkulationstabelle berechnet und beim Anfangssaldo des nächsten Zeitraums weggelassen wurden.

F8: Die Verteilungen auf der RM/PM-Seite sind zwar vorhanden, werden aber nicht in das Arbeitsblatt gepullt.

A8: Lesen Sie diese Tipps zur Problembehandlung:

• Untersuchen Sie den Datumsbereich, der im Arbeitsblatt Abgleichen verwendet wird.
• Überprüfen Sie, ob die Verteilungen in den tabellen PM10100 oder PM30600 für PM vorhanden sind. (oder für RM: suchen Sie die RM10101 oder RM30301) Überprüfen Sie die Datumsangaben für diese Verteilungen, um sicherzustellen, dass sie innerhalb des Bereichs liegen, den Sie für das Arbeitsblatt eingegeben haben. Es ist wichtig, diese in den RM- oder PM-Verteilungstabellen zu finden und sich nicht ausschließlich auf nachgedruckte Buchungsjournale für instance zu verlassen.
• Wenn Sie die Verteilungen in den RM- oder PM-Tabellen finden, sehen Sie sich diese Verteilungen im Dokument im Front-End an. Haben sie eine Verteilungsart von PAY oder REC oder AVAIL? Dies sind die einzigen Typen, die in älteren Versionen auf der RM- oder PM-Seite in die Abgleichstabelle gepullt werden. (Update: Guthaben Karte Zahlungen können zu einer Verteilung an das AP-Konto mit einer Art VON CASH führen, in der es sich in der Tabelle befindet, aber in der Tabelle "Abgleichen mit GL" diese Verteilung auf der linken Seite nicht angezeigt wurde. Also nur ein Anzeigeproblem mit der Kalkulationstabelle und kein Datenproblem. Dies scheint jedoch in Microsoft Dynamics GP 2016 kein Problem zu sein, da der CASH-Typ jetzt ordnungsgemäß in der Kalkulationstabelle angezeigt wird und daher auf dem Weg behoben wurde.)

F9: Kann das Fenster "Mit GL abstimmen" in anderen Währungen angezeigt werden?

A9: Das Fenster "Mit GL abstimmen", das nur für die Anzeige funktionaler Währungen konzipiert ist. Weitere Informationen finden Sie unter Informationen zu den Salden im Fenster Mit GL abstimmen in Microsoft Dynamics GP.