Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, warum sich der Kontostand des Kreditorenkontos oder der Kontostand der Forderungen im Hauptbuch vom Gesamtbetrag unterscheidet, der im Historischen Überalterungsbilanzbericht von Microsoft Dynamics GP fällig ist. Am Ende dieses Artikels finden Sie häufig gestellte Fragen.
Gilt für: Microsoft Dynamics GP
Ursprüngliche KB-Nummer: 866570
Die Versöhnung mit GL-Routine war neu bei Microsoft Dynamics GP 10.0 (SP2). Diese Routine generiert eine Microsoft Office Excel-Kalkulationstabelle. Mit diesem Tabellenblatt können Sie Transaktionen im Kreditorenmanagement oder im Forderungsmanagement abgleichen, die im Hauptbuch gebucht wurden. Dieser Vorgang generiert keine korrekten Transaktionen. Dieser Prozess kann Ihnen jedoch dabei helfen, die Transaktionsunterschiede zu ermitteln, die in diesem Abschnitt aufgeführt sind. Um das Fenster "Abgleich mit GL" zu öffnen, zeigen Sie im Menü Microsoft Dynamics GP auf Extras, zeigen Sie auf Routinen, zeigen Sie auf Finanzen, und wählen Sie dann Abgleich mit GL aus.
Nachfolgend finden Sie eine laufende Liste der Probleme, die wir gesehen haben, die zu Unterschieden führen können:
Nicht alle GL-Batches werden gepostet. (Die Tabelle "Abgleich mit GL" berichtet nur über gepostete Einträge.)
Der Bericht "Historisches Altersbilanzbericht" wird mit Druckeinschränkungen gedruckt. Drucken Sie den Bericht "Historische Altersanalyse der Summen- und Saldenliste" erneut mit einer Datumsbegrenzung.
Nicht alle Kreditorenkonten oder alle Forderungskonten werden im Hauptbuch angezeigt. Stellen Sie sicher, dass Sie alle Verbindlichkeiten oder alle Forderungen im Hauptbuch einsehen.
Chargen im Kreditorenmanagement oder im Forderungsmanagement wurden ins Hauptbuch gebucht. Der Batch im Hauptbuch wurde geändert oder bearbeitet, bevor er gepostet wurde.
Anpassungen des Kreditorenkontos oder des Forderungskontos können direkt in das Hauptbuch eingegeben worden sein. Diese Transaktionen aktualisieren das Konto im Hauptbuch. Diese Transaktionen aktualisieren jedoch nicht den Bericht "Alter alter Testbilanz".
Der Datumsbereich des detaillierten Teststandsberichts im Hauptbuch stimmt nicht mit dem Datumsbereich des Berichts über den Bilanzbericht über die Historische Altersabschreibung im Kreditwesen oder im Forderungsmanagement überein. Wenn Sie den Bericht "Historische Altersprobebilanz" drucken, aktivieren Sie das Kontrollkästchen GL-Buchungsdatum im Bereich "Transaktionen für Bericht verwenden zu".
Transaktionen wurden im Debitorenmanagement oder im Forderungsmanagement gebucht. Diese Transaktionen wurden jedoch nicht in das Hauptbuch gebucht, wenn es sich um Eröffnungsbestände handelte. Wenn das Kontrollkästchen "Nach Hauptbuch posten" im Fenster "Posten einrichten" für die Einkaufsserie oder die Vertriebsserie nicht aktiviert ist, werden die Transaktionen in der Kreditorenverwaltung oder der Debitorenverwaltung gebucht. Diese Transaktionen werden jedoch nicht im Hauptbuch gebucht.
Das Kontrollkästchen "Rabatte nachverfolgen" in GL ist im Setupfenster "Kreditorenverwaltung" oder im Setupfenster "Forderungsmanagement" 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 Bericht "Detaillierte Testbilanz" im Hauptbuch angezeigt. Die Rechnung zeigt jedoch die Bruttorechnungssumme für den Saldo der historischen Altersabschreibung im Kreditwesen oder im Forderungsmanagement an.
Dokumente wurden in einem anderen Zeitraum als ursprünglich veröffentlicht. Der Bericht "Detaillierte Versuchsbilanz" in der Hauptbuchhaltung stimmt möglicherweise nicht mit dem Bericht "Historische Altersversuchsbilanz" überein. Angenommen, eine Rechnung wurde am 1.1.2007 eingegeben. Diese Rechnung wurde am 2.1.2007 ungültig. Für den Zeitraum 01.02.2007 - 28.02.2007 wird ein Bericht über die detaillierte Hauptbuch-Saldenliste gedruckt. Die ungültige Transaktion wird im Bericht angezeigt. Wenn ein Alter im Verlauf des Testabgleichs mit demselben Datumsbereich gedruckt wird, wird das ungültige Dokument nicht im Bericht gedruckt, da er nichtigiert wurde.
Wenn Sie für einen bestimmten Zeitraum den Kontostand der Guthabenkonten oder den Kontostand der Forderungen in General Ledger in den Bericht "Alter alter Alter" für einen bestimmten Zeitraum abwägen möchten, müssen die Saldos aus dem Bericht über den Saldo der historischen Altersabstände mit der Nettoänderung des detaillierten Testguthabens im Hauptbuch für den gleichen Zeitraum in Einklang gebracht werden.
Wenn Sie für einen Tag, der nicht in einem bestimmten Zeitraum liegt, den Kontostand der Kreditoren oder forderungen in General Ledger abwägen möchten, bestimmen Sie, ob die Verbindlichkeitenverwaltung oder das Forderungsmanagement jemals ausgeglichen wurde. Wenn das Kreditverwaltungs- oder Forderungsmanagement nie ausgeglichen wurde, sind die Anfangssaldos 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 Chargen möglicherweise nicht ordnungsgemäß in das General Ledger, in das Kreditorenmanagement oder in das Forderungsmanagement gebucht.
Wenn Sie den Bericht "Historische Altersprüfungssummenbilanz" drucken, haben Sie im Bereich "Ausschließen" die folgenden Kontrollkästchen nicht ausgewählt.
Aktivieren Sie diese Auswahlkästchen, und drucken Sie dann den Bericht "Historische Darlehenssaldenprüfung" aus.
Notiz
Wenn Sie den Bericht "General Ledger Detailed Trial Balance" und den Bericht "Historische OP-Liste" nach bestimmten Dokumenten abgleichen möchten, deaktivieren Sie das Kontrollkästchen "Vollständig bezahlte Dokumente".
- Nicht gebuchte angewandte Kreditzdokumente
- Nullsaldo
- Aktivität
Wenn Sie das Multicurrency Management verwenden und den Wert neu bewerten, haben Sie ausgewählt, auf das Einkaufs-/Verkaufs-Offset-Konto zu buchen.
Kreditkartenbeträge, die im Transaktionseintragsfenster für Verbindlichkeiten für eine Rechnung eingegeben wurden. Dies kann zu einem Ungleichgewicht bei der Abstimmung der Kreditorenverwaltung mit dem Hauptbuch führen, da nur die Nettoänderung auf das Hauptbuchmodul gebucht wird. (Das heißt, es scheint, als ob GL-Transaktionen fehlen, aber die Beträge auf der GL-Seite werden in einen GL-Eintrag eingegrenzt, während die PM-Seite drei Datensätze anzeigen kann. Sie sollten jedoch in späteren Versionen weiterhin übereinstimmen und ordnungsgemäß zum Abschnitt "Übereinstimmende Transaktionen" wechseln.)
Wenn es Unterbrechungen oder Probleme bei einem Verarbeitungsbatch für Verbindlichkeiten oder Forderungen gab und die Transaktionen gleichzeitig in den Tabellen 'Verarbeitung' und 'Offene Posten' vorhanden sind, führt das Löschen des RM- oder PM-Batches in Microsoft Dynamics GP zu Problemen. In diesem Fall sieht der Benutzer in der Regel die Datensätze in beiden Tabellen und entscheidet, dass der Arbeitsbatch nicht benötigt wird, sodass er ihn einfach in Microsoft Dynamics GP löscht. Da die Tabellen "Arbeit" und "Öffnen" eine Verteilertabelle gemeinsam nutzen, werden durch das Löschen des Batches in Microsoft Dynamics GP auch die Verteilungsdatensätze entfernt. Das Endergebnis ist, dass der Transaktionsheaderdatensatz vorhanden ist, aber es gibt keine übereinstimmenden Verteilungen auf der RM- oder PM-Seite, aber GL wurde ordnungsgemäß aktualisiert. Dieses Problem wird in der nächsten Version von Microsoft Dynamics GP berücksichtigt.
Verteilungen können im Abschnitt "Potenziell übereinstimmend" mit unterschiedlichen Beträgen angezeigt werden, wenn Rabatte vorhanden sind. Damit es zu einem Abgleich kommt, sollten die Rabatt-GL-Konten in das PM-/RM-Konto integriert worden sein, bevor der Prozess "Reconcile to GL" ausgeführt wird. Schließen Sie die Kalkulationstabelle, und führen Sie sie auch mit den aufgeführten Gl-Rabattkonten erneut aus.
Verteilungen fehlen möglicherweise auf der PM/RM-Seite, wenn der Typ (CASH, PAY, PURCH) geändert wurde. Auf der Kalkulationstabelle wird das Konto nur für die GL-Seite verwendet. Das Konto wird nicht auf der PM/RM-Seite verwendet. Die PM/RM-Seite verwendet den PAY- oder REC-Typ unabhängig davon, welches Konto verwendet wird. Deshalb sollten Sie unbedingt alle 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 die Kalkulationstabelle neu generieren. (Dies war ein Problem in früheren Versionen für Kreditkartenzahlungen mit dem CASH-Typ und das Buchen auf das AP-Konto, aber diese Datensätze werden in GP 2016 angezeigt, sodass es kein Problem mehr zu geben scheint.)
Überprüfen Sie das Anwendungsdatum und das Hauptbuch-Postdatum in der Tabelle "Anwendung" für Mehrwährungs-Transaktionen im Vergleich zum tatsächlichen Datum, an dem sie im Hauptbuch gebucht wurden. Zum Beispiel wurde am 22. Januar eine Gutschrift vom 31. Dezember auf eine Rechnung vom 5. Dezember angewendet, und das Datum der Anwendung und das GL-Buchungsdatum blieben der 22. Januar. Beim Veröffentlichen des GL-Batches hat der Benutzer das Datum jedoch auf den 31. Dezember geändert. In diesem Fall listet die Kalkulationstabelle "Abgleich mit GL" für den Monat Dezember den realisierten Gewinn/Verlustbetrag auf beiden Seiten auf, und sie scheinen miteinander in Einklang zu treten. Der HATB-Bericht erkennt jedoch den realisierten Gewinn-/Verlustbetrag noch nicht und wird im Vergleich zu GL um diesen Betrag abweichen, da er laut dem Anwendungsdatensatz erst im Januar angewendet oder gebucht wurde.
Häufig gestellte Fragen
F1: Ist die Vergleichstabelle mit GL eine echte Erstattung für Verbindlichkeiten/Forderungen an GL?
A1: Die Abgleichsfunktion mit GL ist ein Problembehandlungstool , mit dem Benutzer nicht übereinstimmende Verteilungen zwischen RM/PM und GL erkennen können. Es war nicht notwendigerweise darauf ausgelegt, sich an die HATB zu binden und das war nicht der beabsichtigte Zweck, obwohl wir wissen, dass kunden es tun. Die Kontostände auf der "Abgleichen mit GL"-Tabelle sind die besten Schätzungen, die durch einfache Addition/Subtraktion der Verteilungen in der Tabelle ermittelt werden. Während die Salden auf der HATB fast jede Tabelle berücksichtigen und viel komplexere und genauere Salden sind, decken sich die beiden daher oft nicht.
Der wahre Abgleich sollte zwischen dem RM- oder PM Historical Aged Trial Balance (HATB) und den GL Trial Balance-Berichten bestehen. Wenn diese Übereinstimmungen übereinstimmen, müssen Sie das Tool "Abgleichen mit GL" für diesen Monat nicht unbedingt ausführen. Die GL-Tabellen bestehen aus Lastschriften und Gutschriften, und die Tabellen, aus denen die HATB abgerufen wird, sind Transaktionsheader und wenden Datensatztabellen an. Kunden baten also um eine Möglichkeit, die Verteilungen in GL mit den Verteilungstabellen in RM oder PM abzugleichen, um Unterschiede auf dieser Ebene zu finden. Dies ist also der Grund, warum die Versöhnung mit GL Routine erstellt wurde. Es sollte ein Tool zur Problembehandlung sein, um Verteilungen mit Verteilungen zwischen den Modulen zu vergleichen, um fehlende Verteilungen zu identifizieren, die Sie möglicherweise wieder zu einer fehlenden Transaktion aus dem HATB führen können. Verwenden Sie also das Tool "Abgleich mit GL" lediglich als Hilfe, um die HATB mit der GL-Saldenbilanz abzustimmen. Wenn der HATB- und GL TB-Saldo besteht, muss das Tool "Versöhnen mit GL" für diesen Monat nicht wirklich ausgeführt werden.
F2: Sollten die Summen auf der Kalkulationstabelle "Vergleich mit GL" mit den Summen auf der HATB übereinstimmen?
A2: Nein. Die Summen in der Tabelle "Abgleichen mit GL" sind nur eine einfache Addition/Subtraktion der Verteilungsdatensätze in dieser Tabelle und berücksichtigen keine anderen Tabellen. Während die HATB völlig unterschiedliche Tabellen verwendet, um einen Saldo mithilfe der Transaktionstabellen zu berechnen und Aufzeichnungstabellen anzuwenden, handelt es sich um eine viel komplexere Berechnung. Aufgrund der verschiedenen Berechnungsmethoden/Tabellen, die zum Abrufen der Balancen verwendet werden, wird erwartet, dass die Kalkulationstabelle "Abgleich mit GL" nicht in die Alterungsbilanzen der HATB-Berichte eingebunden wird und die Abstimmung erschwert. Es ist nicht notwendig, die Saldos auf dem GL-Arbeitsblatt mit dem HATB-Bericht abzugleichen.
Wir empfehlen, die Summen in der Vergleichstabelle mit GL zu ignorieren, und verwenden Sie einfach die Abschnitte "Nicht übereinstimmend" und "Potenziell übereinstimmend", um zu ermitteln, ob dies auch einen Unterschied zwischen GL TB und HATB erklären kann. Die Übereinstimmung mit der GL-Kalkulationstabelle 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 die HATB mit der GL TB übereinstimmt, wäre es tatsächlich nicht erforderlich, die Übereinstimmung mit GL-Hilfsprogramm für diesen Monat auszuführen, da es keine Unterschiede gibt, die identifiziert werden müssen.
Wenn Sie den Saldo auf der GL-Tabelle weiterhin mit dem Saldo auf der HATB verknüpfen 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 noch weitere Gründe vorliegen, die noch nicht identifiziert wurden. Da dieser Abgleich nicht notwendig ist zwischen dem einfachen Gesamtsaldo auf der GL-Tabelle und dem komplexeren berechneten Saldo im HATB-Bericht und dies nicht der beabsichtigte Zweck dieses Abstimmungswerkzeugs ist, wird es als Beratungsaufwand angesehen, sich mit Ihren Daten zu befassen, um Ihnen zu helfen, diese aufeinander abzustimmen.
F3: Was sollte 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 Zeitunterschiede. Stellen Sie sicher, dass alle GL-Batches bereitgestellt werden. Wenn sie wirklich auf der GL-Seite fehlen, müssen Sie einen Anpassungsjournaleintrag direkt in GL eingeben, um die GL-Verteilungen zu erstellen.
F4: Was sollte ich tun, wenn Ausschüttungen auf der 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 auf Zeitpunktunterschiede. Recherchieren Sie außerdem, 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 nur. Die Frage wird also, wie erhalte ich die Verteilungen in RM oder PM, wenn die Transaktion vorhanden ist? Denken Sie zunächst daran, dass die Verteilungstabellen in RM oder PM nicht für andere Zwecke oder Berichte in GP verwendet werden, außer dieser Abgleichstabelle. Ist es also wirklich notwendig, sie wieder in RM oder PM einzubringen? Bewerten Sie, ob es sich lohnt, eine Tabelle aufzufüllen, die an keiner anderen Stelle verwendet wird.
Wenn Sie sich jedoch dafür entscheiden, die PM-Verteilungstabelle zu beheben, müssten Sie das Dokument ungültig machen, damit die angewendeten Datensätze wieder in den offenen Zustand versetzt 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 GL gepostet und nicht über GL gepostet wird. Löschen Sie den GL-Batch, der von der Void erstellt wurde. Geben Sie das Dokument dann erneut in "Verbindlichkeiten" ein, damit die Transaktionen und Verteilungen neu erstellt werden. Stellen Sie sicher, dass Sie dafür den GL-Batch ungültig machen. Anschließend wird das neue Dokument erneut auf die geöffneten Dokumente angewendet, und sie sollten wieder in den Verlauf verschoben werden.
Um dies in der RM-Verteilungstabelle zu beheben, müssen Sie beide Seiten der Rechnung und Zahlung entfernen, beide neu eingeben und den Batch im GL löschen.
F5: Die Transaktionen im Abschnitt "Potenziell übereinstimmend" scheinen übereinzustimmen. Warum sind sie nicht im Abschnitt "Übereinstimmungen"?
A5: Es gibt mehrere Felder, die für jeden Verteilungsdatensatz übereinstimmen. 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" platziert. Zum Beispiel, hier sind die Felder, die für PM mit GL abgeglichen werden:
Kreditorenmanagement -- GL
Gutscheinnummer -- Ursprungskontrollnummer
TRX-Quelle - Ursprungs-TRX-Quelle
Veröffentlichungsdatum - Transaktionsdatum
Bei Kontobetrag - Lastschriftbetrag oder Kreditbetrag
F6: Wenn ich die fehlenden Verteilungen in GL oder RM/PM eingebe und die Kalkulationstabelle "Abgleich mit GL" erneut ausführe, verschieben sich dann die nicht übereinstimmenden oder potenziell übereinstimmenden Elemente in den Abschnitt "Übereinstimmung"?
A6: Nein. Wenn die Transaktionen getrennt eingegeben werden, werden sie unterschiedliche Gutscheinnummern und Transaktionsquellcodes haben. Das Buchungsdatum und die Beträge können am besten übereinstimmen, was sie im Abschnitt "Potenziell übereinstimmend" der Kalkulationstabelle platzieren könnte.
F7: Warum stimmt der Endsaldo auf einer monatlichen oder vierteljährlichen Tabelle nicht mit dem Anfangssaldo im nächsten monatlichen oder vierteljährlichen Arbeitsblatt überein?
A7: Wenn das Endsaldo eines Zeitraums nicht mit dem Anfangssaldo des nächsten Zeitraums übereinstimmt, liegt es häufig an verwaisten Verteilungsdatensätzen, die keinen zugeordneten Kopfzeilendatensatz in der Unterbuchtabelle aufweisen. Der Endsaldo wird von Excel direkt in der Kalkulationstabelle berechnet. Es nimmt einfach den Anfangssaldo für diesen Zeitraum oben auf der Kalkulationstabelle und addiert/subtrahiert die Verteilungsdaten, die auf der Kalkulationstabelle angezeigt werden, um zum Endsaldo zu gelangen. Andererseits wird im nächsten Zeitraum der Anfangssaldo berechnet, indem eine einfache Berechnung von Soll-/Haben für die Verteilungseinträge in der SQL-Tabelle durchgeführt wird. Die gespeicherte Prozedur verbindet sich mit der Tabelle der Kopfdatensätze, sodass keine Verteilungen enthalten sind, denen ein Kopfdatensatz fehlt. Das Endergebnis könnte sein, dass einige Verteilungen in das Endsaldo der vorherigen Kalkulationstabelle berechnet und vom Anfang des Saldos für den nächsten Zeitraum weggelassen wurden.
Q8: Die Verteilungen auf der RM/PM-Seite sind vorhanden, werden jedoch nicht in die Tabelle gezogen.
A8: Lesen Sie die folgenden Tipps zur Problembehandlung:
- Überprüfen Sie den Datumsbereich, der in der Kalkulationstabelle verwendet wird.
- Stellen Sie sicher, dass 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 in den Bereich fallen, den Sie für die Kalkulationstabelle eingegeben haben. Es ist wichtig, diese in den RM- oder PM-Verteilertabellen zu finden und sich nicht ausschließlich auf neu druckbare Journale 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 den Verteilungstyp PAY, REC oder AVAIL? Dies sind die einzigen Typen, die in älteren Versionen auf der RM- oder PM-Seite in die Abgleichstabelle eingefügt werden. (Update: Kreditkartenzahlungen können eine Verteilung an das AP-Konto mit einem Typ von CASH darauf erzeugen, in dem sie sich in der Tabelle befindet, aber die Übereinstimmung mit GL-Kalkulationstabelle hat diese Verteilung auf der linken Seite nicht angezeigt. Daher ist nur ein Anzeigeproblem mit der Kalkulationstabelle und kein Datenproblem. Dies scheint jedoch kein Problem in Microsoft Dynamics GP 2016 zu sein, da der CASH-Typ jetzt korrekt auf der Kalkulationstabelle angezeigt wird, daher wurde dies auf dem Weg behoben.)
F9: Kann das Fenster "Vergleich mit GL" in anderen Währungen angezeigt werden?
A9: Das Fenster "Versöhnen mit GL" ist so konzipiert, dass nur funktionale Währungen angezeigt werden. Weitere Informationen finden Sie unter Informationen zu den Saldos im Fenster "Vergleich mit GL" in Microsoft Dynamics GP.