Unerwartet taucht ein GLTRX-Batch im Finanzbatcheintrag in Microsoft Dynamics GP auf.

Dieser Artikel enthält eine Lösung für ein Problem, bei dem ein unerwarteter GLTRX-Batch im Finanzbatcheintrag in Microsoft Dynamics GP angezeigt wird.

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

Symptome

In Microsoft Dynamics GP beginnt die Batch-ID mit "GLTRX", aber der Batch stammt nicht aus dem Hauptbuch.

Ein GLTRX-Batch wurde systemgeneriert und ist unbekannt, warum er angezeigt wird.

Sobald der Batch gepostet wurde, wenn Sie versuchen, das Quelldokument wieder zu vergrößern, erhalten Sie die folgende Meldung:

Der Transaktionsverlauf ist für diese Transaktion nicht vorhanden.

Ursache

Diese Funktionsänderung begann mit Microsoft Dynamics GP 9.0.

Lösung

Diese Batches werden vom System generiert, das angibt, dass eine Anpassung im Hauptbuch erforderlich war, um die Beträge zu korrigieren. Unter normalen Umständen sollten diese GLTRX-Kostenanpassungsbatches über GL gebucht werden.

Automatische Kostenänderungen in der Hauptbuchhaltung

Ab Microsoft Dynamics GP 9.0 generiert das System automatisch General Ledger-Anpassungen, wenn ein Artikel aus dem Bestand verkauft oder verbraucht wird und die Kosten der Belegschicht des Artikels anschließend geändert werden. Jeder dieser General Ledger-Anpassungen wird eine Referenznummer zugewiesen.

Weitere Informationen zu Kostenänderungen erhalten Sie, indem Sie auf die folgenden Artikelnummern klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen: 939912 Informationen zur Berechnung der Lagerbestandskosten und zur Wartung dieser Kosten im Bestand in Microsoft Dynamics GP

4094695 So finden Sie heraus, welcher Beleg durch die Kostenanpassung beeinflusst wurde

Was geben die Referenznummern an?

Die Referenznummern können in zwei verschiedene Abschnitte unterteilt werden. Beide Abschnitte haben eine Rolle bei der Angabe, welche Funktion für das Entfernen der Elemente aus dem Bestand verantwortlich war und welche Funktion für die Änderung der Kosten verantwortlich war.

1. Abschnitt 1 oder Präfix– Gibt an, welche Funktion das Element aus dem Bestand verbraucht oder entfernt hat.

   Nachfolgend finden Sie eine Liste der Präfixe, die sie im Feld "Referenz" einer Transaktion in einem GlTRX-Batch (Cost Adjustment) sehen würden, und eine Beschreibung, warum dieses Präfix verwendet werden würde. Das Feld "Verweis" finden Sie in den Fenstern "Transaktionseintrag", "Detailabfrage" und "Journaleintragabfrage".

   • BOM - Dies stammt aus einer Bill of Materials-Transaktion. Beispielsweise würden Sie diese Referenz finden, wenn eine BOM-Assembly-Transaktion einen Artikel aus dem Bestand verbraucht hat und die Kosten später aufgrund einer POP-Kaufpreisabweichung (PPV) oder einer Durchschnittskostenänderung geändert wurden.

   • INV – Dies stammt aus einer Rechnungstransaktion, die aus dem Modul "Invoicing" erstellt wurde. Wenn z. B. eine Rechnungstransaktion (in der Rechnungsstellung) einen Artikel aus dem Bestand verbraucht hat und die Kosten später aufgrund eines PPV für die Auftragsverarbeitung oder einer durchschnittlichen Kostenänderung angepasst wurden, sehen Sie diese Referenz.

   • IVT – Dies stammt aus einer Bestandsübertragungstransaktion. Wenn beispielsweise ein Artikel über die Artikelübertragung verbraucht wurde und die Kosten später aufgrund eines PPV (Preisabweichung beim Einkauf) oder Auswirkungen auf die Durchschnittskosten geändert wurden, würden Sie diesen Verweis sehen.

   • IVA – Dies stammt aus einer Bestandsanpassungstransaktion. Wenn z. B. eine Transaktion zur Verringerung der Lageranpassung einen Artikel aus dem Bestand verbraucht hat und die Kosten später aufgrund eines PPV auf einer Rechnung oder einer durchschnittlichen Kostenwelligkeit geändert wurden, würden Sie diese Referenz sehen.

   • IVV : Dies stammt aus einer Bestandsabweichungstransaktion. Wenn beispielsweise eine Transaktion zur Verringerung der Bestandsabweichung einen Artikel aus dem Bestand verbraucht hat und die Kosten später aufgrund einer PPV auf einer Rechnung oder einer durchschnittlichen Kostenwelligkeit geändert wurden, würden Sie diese Referenz sehen.

   • SALES - Dies stammt aus einer Verkaufsauftragsverarbeitungs-Rechnungstransaktion. Wenn beispielsweise eine Verkaufsrechnung einen Artikel aus dem Bestand entnommen hat und die Kosten später aufgrund einer Preisabweichung auf einer Rechnung geändert wurden oder eine Änderung der Durchschnittskosten erfolgte, würde dies als Referenz erscheinen.

   • PRTN – Dies kommt aus einer Rückgabetransaktion der Bestellabwicklung, bei der die Rückgabe die Artikelkosten beeinflusst.

   • MCTE – Dies stammt aus einer Fertigungskomponententransaktion. Wenn beispielsweise ein Element im Fenster "Komponententransaktionseintrag" ausgegeben (verbraucht) wurde und die Kosten später aufgrund eines PPV (Preisdifferenz) oder einer Durchschnittskostenänderung geändert wurden, würden Sie diese Referenz sehen.

   • MRCT - Dies stammt aus einer Fertigungsbelegtransaktion. Wenn z. B. ein Artikel im Fenster "Fertigungseingangsbuchung" zurückgespült und verbraucht wurde und die Kosten später aufgrund eines PPV oder einer Änderung der durchschnittlichen Kosten geändert wurden, würden Sie diesen Verweis sehen.

   • MCLS -Dies kommt aus dem Schließen eines Fertigungsauftrags über den Close-Prozess oder während eines Schnell-MO (schnelle MOs werden automatisch geschlossen). Wenn ein Benutzer beispielsweise einen MO schließt und Artikel vorhanden sind, die auf "Backflush" (Verbrauch) festgelegt sind, und die Kosten später aufgrund eines PPV oder einer Änderung der durchschnittlichen Kosten angepasst wurden, würden Sie diesen Verweis sehen.

   • STCK : Dies stammt aus der Varianztransaktion "Item Stock Count Variance". Wenn beispielsweise eine Bestandsanzahlanpassung einen Artikel aus dem Bestand verbraucht hat und die Kosten später aufgrund eines PPV oder einer durchschnittlichen Kostenwelligkeit geändert wurden, würden Sie diese Referenz sehen.

   • FSSC - Dies ergibt sich aus dem Verkauf eines Teils bei einem Serviceeinsatz. Beispielsweise wurde ein Artikel zu einem Preis in den Bestand aufgenommen, und die Kosten wurden später aufgrund einer Rechnungsübereinstimmung geändert, was zu diesem Verweis führen würde.

   • FSRMA - Dies stammt aus einer RMA. Sie haben z. B. eine Menge eines Artikels zu einem Preis. Sie erstellen eine Kredit-RMA und erhalten den Artikel. Anschließend verschrotten Sie den Artikel (wodurch der bereits in Ihrem Bestand enthaltene entfernt wird), und sollten sich später aufgrund eines Rechnungsabgleichs die Kosten für diesen Artikel ändern, würden Sie dies als Referenz sehen.

   • FSRTV - Dies stammt von einem RTV. Sie erstellen z. B. eine Kredit-RTV. Sie versenden einen Artikel zu einem bestimmten Preis, und die Kosten wurden später aufgrund eines Rechnungsabgleichs geändert; dabei würde diese Referenz angezeigt werden.

   • FSWO - Dies ergibt sich aus der Verwendung eines Teils in einem Depot-Arbeitsauftrag. Zum Beispiel erstellen Sie einen Arbeitsauftrag und verwenden ein Teil aus dem Fenster "Teileinformationen" zu einem bestimmten Preis, und die Kosten wurden später aufgrund eines Rechnungsabgleichs geändert. Dies würde sich in der Referenz widerspiegeln.

   • PA - Dies stammt aus einer Project Accounting-Transaktion. Wenn beispielsweise eine PA-Bestandsübertragung einen Artikel aus dem Lagerbestand verbraucht hat und die Kosten später aufgrund eines PPV bei einer Rechnungsabstimmung oder einer Durchschnittskostenkorrektur geändert wurden, würden Sie diesen Verweis sehen.

   • POP -- Dies stammt aus einem Bestellabwicklungs-Lieferschein. Wenn zum Beispiel ein Artikel in einem Modul durch eine Überschreibung verbraucht wurde und später die Lieferung zu einem anderen Preis als beim Verbrauch eingebracht wurde, wird dieser Verweis angezeigt.

   • RECON – Dieser Verweis würde angezeigt, wenn der neu ausgewertete Outflow vom Inventory Reconcile Utility erstellt wurde. Ein Grund, warum IV-Abstimmung einen Abflussdatensatz erstellen muss, ist, wenn in der IV10201 nicht genügend Mengen vorhanden sind, um die in der IV10200 verkaufte Menge abzudecken.

   • CONV – Dieser Verweis würde angezeigt, wenn der neu ausgewertete Outflow durch das Upgrade erstellt wurde. Das Upgrade von einer älteren Version von Microsoft Dynamics GP auf 9, 10 oder GP2010 muss möglicherweise einen Outflow erstellen, wenn ein Belegdatensatz zum Zeitpunkt der Konvertierung teilweise verkauft wurde.

   • PRCT - Sie würden diesen Verweis sehen, wenn der Artikel bei einer In-Transit-Übertragung überschrieben wurde und dann später zu einem anderen Preis eingezogen wurde.

   Ausnahme: Wenn Mengenüberschreibungen im Bestand zulässig sind und Benutzer eine Außerkraftsetzung zulassen, wird das Präfix möglicherweise nicht wie oben aufgeführt angezeigt. Stattdessen kann sie auf die Inflowtransaktion verweisen, die die Menge wieder in den Bestand brachte. Sehen Sie sich das Beispiel im folgenden Abschnitt mit dem Namen "Inventory Example" an.

2. Abschnitt 2 oder Suffix – Gibt an, welche Funktion die Kosten des verbrauchten Elements geändert hat.

   • Kein Suffix – Wenn nur ein Präfix vorhanden ist, wurde die Kosten mithilfe einer Bestandsanpassung geändert.

   • RCTxxxx - Gibt das Einkaufsdokument an, das die Kostenanpassung verursacht hat.

   • AdjustedCost – Gibt an, dass das Kostenprogramm anpassen die Kosten der verbrauchten Ebene geändert hat.

   • PO – Gibt an, dass der PO im Fenster "Auftragsstatus bearbeiten" manuell geschlossen wurde, nachdem er teilweise oder vollständig erhalten und verkauft und dann teilweise in Rechnung gestellt wurde.

Beispiel für Bestellungen:

Gehen Sie davon aus, dass Sie die folgenden vier Transaktionen in der folgenden Reihenfolge ausgeführt haben:

1. Geben Sie einen Bestellauftrag (PO2127) mit einem neuen Artikel für eine Menge von 1 @$1,00 ein.

2. Geben Sie einen Versandbeleg beim Preis von 1,00 $ ein und posten Sie ihn (Zu diesem Zeitpunkt wird der Bestand mit 1,00 $ bewertet). Hinweis: RCT1229

3. Verkauf des neuen Artikels zu einem Preis von 1,00 $ in der Verkaufsauftragsbearbeitung. (An diesem Punkt ist der Bestand null, da wir alle Artikel verkauft haben). Hinweis: STDINV2279

4. Geben Sie die Rechnung in der Bestellabwicklung für 1,05 $ ein oder gleichen Sie sie ab. (Dies bedeutet, dass der Preis zum Zeitpunkt des Verkaufs falsch war und er für $1,05 und nicht für $1,00 hätte verkauft werden sollen.). Hinweis: RCT1230

Es gibt einen PPV für die 5 Cent (Differenz zwischen den Kosten des Versandbelegs und den Kosten des Rechnungsbelegs in der Auftragsverarbeitung, und dieser Unterschied wird mit den Bestellrechnungsverteilungen erfasst.

Bei der Buchung der Rechnung in der Auftragsverarbeitung wird automatisch eine General Ledger-Kostenanpassung in einem FINANZ-GLTRX-Batch erstellt. Ein Update-Detailbericht (Purchase Receipts Update Detail Report, PRUD) (siehe unten) wird gedruckt, nachdem das Kostenabweichungsjournal angibt, dass eine Kostenanpassung vorhanden war.

Der erstellte Journaleintrag wird in General Ledger wie der folgende Screenshot angezeigt:

Quelldokument = GJ
Batch-ID beginnt mit GLTRX
Das Feld "Referenz/Verteilungsreferenz" wird wie oben beschrieben in die beiden Teile aufgeteilt. Unser "Präfix" ist "VERTRIEB", da es sich um eine SOP-Rechnung (STDINV2279) handelte, die die nun neu bewertete Belegebene verbraucht hat. Unser "Suffix" ist die Dokumentnummer der Quittung (RCT1230), die dazu führte, dass die Neubewertung erfolgt.

Bestandsbeispiel:

Gehen Sie davon aus, dass Sie die folgende 2 Transaktion in der folgenden Reihenfolge ausgeführt haben:

1. Geben Sie eine Verkaufsrechnung aus der Auftragsbearbeitung für einen Artikel ein, den Sie nicht vorrätig haben, mit einer Menge von 1. Sie werden aufgefordert, die Bestandsmengen anzupassen, da Sie keine auf Lager haben, und die aktuellen Kosten von 2,00 $ werden verwendet. HINWEIS: STDINV2280

2. Geben Sie eine Bestandserhöhung von 5,00 $ in den Bestand ein und verbuchen Sie diese. HINWEIS: Dokumentnummer: 00000000000000163

Bei der Buchung der Erhöhung der Bestandsanpassung wird automatisch eine General Ledger-Kostenanpassung in einem GLTRX-Batch für Finanzdaten erstellt. PRUD-Bericht unten:

Der erstellte Journaleintrag wird in General Ledger wie der folgende Screenshot angezeigt:

Quelldokument = GJ
Batch-ID beginnt mit GLTRX
Wir unterteilen das Feld "Referenz/Verteilungsreferenz" in die oben besprochenen 2 Teile; unser "Präfix" ist IVA, weil die ursprünglich verbrauchten Mengen technisch nicht verfügbar waren und außer Kraft gesetzt wurden. Aufgrund dieser Ausnahme listet das Feld "Referenz" die IV-Anpassung auf, die wieder in die Mengen eingerechnet wurde.

BOM-Außerkraftsetzungsbeispiel:

1. Angenommen, Sie haben neue Elemente erstellt: BOM FG und BOM COMPONENT 1. Beide Posten sind mit einer durchschnittlichen unbefristeten Bewertungsmethode eingerichtet.

2. Die BOM wurde wie folgt erstellt:

   BOM FG
   +BOM-Komponente 1

   BOM-Komponente 1 ist auch eine fertige BOM-Komponente:

   +BOM COMPONENT 1 (bei Bedarf auf Build festgelegt)
   128 SDRAM

3. Erstellen Sie eine BOM-Assembly für BOM FG. Sie benötigen BOM COMPONENT 1. Da Sie keines haben, wird es eines erstellen und es dann bei der Erstellung von BOM FG verwenden – damit erhalten Sie eine solide Basis für BOM COMPONENT 1.

4. Nehmen Sie eine Erhöhungsanpassung für BOM COMPONENT 1 zu anderen Kosten vor als zu den aktuellen Kosten. Wenn dieser Schritt durchgeführt wird, wird die Transaktion vor der Zusammenstellung der BOM zurückgeführt.

5. Wenn sie beiträge, drucken Sie das Kostenabweichungsjournal. Dieser Bericht ist leer, aber im PRUD-Bericht, der unmittelbar danach gedruckt wird, wird die Abweichungstransaktion angezeigt.

6. Überprüfen Sie den GLTRX-Batch, der in General Ledger erstellt wurde. Der Verweis sollte etwa wie folgt aussehen: BOM00000000000000246 angibt, dass es sich um eine BOM-Transaktion handelte, die das Element und das Dokument 00000000000000246 verwendet hat, das die Neubewertung verursacht hat.

   Notiz

   Bilder sind nicht enthalten, aber dasselbe Konzept gilt wie bei den beiden anderen oben genannten Transaktionen.

Notiz

Informationen zu den unten aufgeführten terminierten GL-Kostenanpassungen.

Das Datum, das für die Transaktionen im GLTRX-Batch verwendet wird, hängt von der Abfluss-Transaktion ab, die neu bewertet wird. Ab Microsoft Dynamics GP 10 SP2 und Microsoft Dynamics GP 9 SP4 verwenden wir nun den letzten Tag des Geschäftsjahres , in dem die verwellte Transaktion erfolgt ist, um nach GL zu posten, wenn die Transaktion vor dem aktuellen Zeitraum erfolgt ist.

Angenommen, Sie haben die folgenden Transaktionen gepostet:

1. Sie haben eine Lieferung mit einem 9/15-Datum gebucht.

2. Sie haben die menge verkauft, die mit dieser Lieferung am 9/17, 10/20, 11/5 und 12/4 verbunden ist.

3. Sie haben den Rechnungsabgleich zu einem anderen Preis mit dem Datum 12/12 gebucht.

Wenn diese Einkaufsrechnung gebucht wird, wird ein GLTRX-Batch in GL erstellt, um die Kostendifferenz wie oben beschrieben zu berücksichtigen. Dieser Batch enthält vier Transaktionen. Sie werden datiert: 9/30, 10/31, 11/30 und 12/12. Jede Kostenanpassungstransaktion im Zusammenhang mit einem Outflow, der in einem Zeitraum vor der Buchung der Rechnung gebucht wurde, wird also mit dem letzten Tag des Monats datiert, in dem sie aufgetreten ist.

Notiz

Informationen zum Dex.ini-Schalter unten.

Fügen Sie die folgende Zeile in die DEX.INI ein, um im Detail in das Hauptbuch zu buchen und die Felder ORCTRNUM, ORMSTRID, ORMSTRNM und ORDOCNUM in den Tabellen GL10001 (GL Buchungsbeträge Arbeit) und GL20000 (GL Jahr-für-Jahr Buchung offen) zu füllen.

Notiz

Die DEX.INI-Datei befindet sich im Datenverzeichnis Ihrer Microsoft Dynamics GP-Installationen 10 und 2010. Sie befindet sich im Codeordner Ihrer Microsoft Dynamics GP 9.0-Installation.

REVALJEINDETAIL=TRUE

Wenn sich die obige Zeile im DEX.INI zu dem Zeitpunkt befindet, zu dem eine Ripple-Kostenanpassungstransaktion erstellt wird, werden die folgenden vier Felder ausgefüllt.

• ORCTRNUM- Enthält die ursprüngliche Dokumentnummer der Auslauftransaktion, z. B. die SOP-Nummer oder die Bestandsdokumentnummer.

• ORMSTRID: Enthält die Elementnummer, die an der Kostenänderung beteiligt ist.

• ORMSTRNM- Enthält den Verweis auf "IV Ripple Transaction".

• ORDOCNUM: Enthält die Dokumentnummer des Belegdatensatzes, der in der IV10200 aktualisiert wird.

Wenn Sie diese Zeile aktuell nicht in der DEX.INI haben, stellen Sie sicher, dass Sie sie nun zu jeder Arbeitsstation hinzufügen, um diese Informationen in Zukunft erfassen zu können.

"Kaufbelege-Aktualisierungsdetails (PRUD) Bericht:"

Sie können dem PRUD-Bericht zusätzliche Details hinzufügen, indem Sie die angefügte Paketdatei importieren.

• Der PRUD-Standardbericht stellt den Journaleintrag, die Dokumentnummern und den Kostenanpassungsbetrag bereit, die im Hauptbuch erfasst werden, wie in den obigen Beispielen zu sehen.

• Der geänderte PRUD-Bericht enthält zusätzliche Felder wie originale und neue Kosten und die Differenz auf Mengenbasis.

PRUD-Berichtspaketdatei

Um verwendet zu werden, muss Microsoft Dynamics GP die Version 9.00.292 oder höher haben. Die geänderten Berichte sind nach Element und Dokument.

• Nach Element stammt aus dem Fenster "Kosten anpassen".

• Das Dokument entstammt einer tatsächlichen Neubewertung (Ripple).