GLTRX Anomaly: Unexplained Batches in Dynamics GP's Financial Entry

Table of Contents

This document addresses a specific issue encountered in Microsoft Dynamics GP where users find an unexpected batch identified by a ‘GLTRX’ Batch ID within the Financial Batch Entry window. These batches, while appearing in General Ledger, do not originate directly from typical General Ledger entries. Understanding the nature and origin of these GLTRX batches is crucial for maintaining accurate financial records within Dynamics GP. This article aims to clarify why these batches appear and what they signify within the system.

Symptoms of an Unexpected GLTRX Batch¶

When encountering this anomaly in Microsoft Dynamics GP, several key symptoms are observed. The most prominent indicator is the presence of a batch in the Financial Batch Entry window where the Batch ID begins with ‘GLTRX’. This prefix itself is a signal that the batch is system-generated and linked to specific automated processes within Dynamics GP, rather than being manually created by a user in General Ledger.

Further investigation reveals that these GLTRX batches do not originate from standard General Ledger transaction entries. Users may find no corresponding manual journal entry or typical GL transaction that would have initiated such a batch. This lack of direct user-initiated origin often leads to confusion and questions about the batch’s purpose and validity.

Another significant symptom manifests after the GLTRX batch is posted. If a user attempts to utilize the Source Document drill-down functionality to trace back the origin of the transaction, the system responds with the message:

Transaction history does not exist for this transaction.

This message confirms that the GLTRX batch is not tied to a conventional, user-initiated transaction history in the same way as standard General Ledger entries. It points towards an automated, system-driven process as the source of these batches.

Cause of GLTRX Batches: Automatic Cost Adjustments¶

The appearance of GLTRX batches is not an error or system malfunction, but rather a designed functionality within Microsoft Dynamics GP, introduced starting with version 9.0. These batches are a direct result of the system’s automatic cost adjustment mechanism within General Ledger.

Specifically, GLTRX batches are generated when the system needs to make adjustments in General Ledger to correct inventory valuation amounts. This automatic adjustment process is triggered by changes in the cost of inventory items after those items have already been sold or consumed. In essence, if the cost of an item’s receipt layer changes after the item has been used in a transaction, Dynamics GP automatically creates a GLTRX batch to reflect this cost correction in the financial records.

Resolution: Understanding and Posting GLTRX Batches¶

The intended resolution for GLTRX batches is not to prevent their creation, as they are a necessary part of the system’s cost management. Instead, the resolution lies in understanding their purpose and ensuring they are correctly posted through General Ledger. These batches are system-generated indicators that a cost adjustment has been made to maintain the accuracy of inventory valuation and related financial accounts.

Under normal circumstances, GLTRX cost adjustment batches should be reviewed and posted through General Ledger just like any other financial batch. Posting these batches ensures that the cost adjustments are properly reflected in the General Ledger, maintaining the integrity of the financial data. Ignoring or deleting these batches can lead to discrepancies between inventory sub-ledger and General Ledger balances.

Automatic Cost Adjustments in General Ledger Explained¶

Since Microsoft Dynamics GP 9.0, the system incorporates a feature for automatic General Ledger adjustments triggered by changes in inventory item costs. This functionality is crucial for businesses employing perpetual inventory systems where accurate and up-to-date inventory valuation is essential.

The core principle behind these automatic adjustments is to ensure that when an item is sold or consumed from inventory, and the cost of the original receipt layer for that item is subsequently changed, the General Ledger is automatically updated to reflect this cost revision. This ensures that the cost of goods sold (COGS) and inventory asset values are accurate, even when purchase costs fluctuate after items have been used in transactions.

Each of these automated General Ledger adjustments is assigned a reference number. This reference number is key to understanding the context and origin of the cost adjustment, providing valuable information about the transactions that triggered the GLTRX batch.

Decoding GLTRX Reference Numbers: Prefix and Suffix¶

The reference numbers associated with transactions within a GLTRX batch are structured to provide insights into the cause and context of the cost adjustment. These reference numbers can be dissected into two distinct sections: a prefix and a suffix. Each section plays a vital role in identifying the processes involved in the cost adjustment.

Section 1: Prefix - Identifying the Outflow Transaction¶

The prefix of the reference number is designed to indicate the originating function or transaction that initially consumed or removed the item from inventory. This prefix provides the context of why the item was taken out of inventory in the first place, setting the stage for understanding why a cost adjustment is now necessary.

The following table outlines common prefixes you might encounter in the Reference field of a GLTRX batch transaction, along with a description of the originating transaction type:

Prefix	Description	Example Scenario
BOM	Bill of Materials Transaction: Indicates the item was consumed through a Bill of Materials transaction, such as a BOM Assembly.	A BOM Assembly transaction consumes a component item from inventory. Later, a Purchase Price Variance (PPV) from a Purchase Order or an average cost ripple changes the cost of that component.
INV	Invoice (Invoicing Module): Indicates the item was consumed via an Invoice transaction created in the Invoicing module.	An Invoice transaction in the Invoicing module sells an item from inventory. Subsequently, a Purchase Order Processing PPV or an average cost ripple adjusts the cost of that item.
IVT	Inventory Transfer Transaction: Indicates the item was consumed through an Inventory Transfer transaction.	An Item Transfer transaction moves an item between inventory locations. If the cost of the item changes later due to a PPV or average cost ripple, a GLTRX batch with the IVT prefix will be generated.
IVA	Inventory Adjustment Transaction: Indicates the item was consumed via an Inventory Adjustment transaction (specifically a decrease adjustment).	A decrease Inventory Adjustment transaction reduces the quantity of an item in inventory. If the cost is later changed due to a PPV on an invoice match or an average cost ripple, this prefix will appear.
IVV	Inventory Variance Transaction: Indicates the item was consumed through an Inventory Variance transaction (specifically a decrease variance).	A decrease Inventory Variance transaction adjusts inventory based on physical counts. Similar to IVA, if a cost change occurs later due to PPV or average cost ripple, IVV will be the prefix.
SALES	Sales Order Processing Invoice Transaction: Indicates the item was consumed through a Sales Order Processing Invoice.	A Sales Invoice transaction sells an item from inventory. A subsequent PPV on an invoice match or an average cost ripple leading to a cost change will result in a SALES prefix.
PRTN	Purchase Order Processing Return Transaction: Indicates the item’s cost change is related to a Purchase Order Processing return transaction where the return process itself alters the item’s cost.	Returning an item via a Purchase Order Processing return can sometimes trigger cost adjustments, particularly if the return impacts the valuation of remaining inventory or related receipts.
MCTE	Manufacturing Component Transaction: Indicates the item was issued (consumed) in the Component Transaction Entry window within Manufacturing.	In Manufacturing, issuing components to a work order through the Component Transaction Entry window consumes inventory. Cost changes arising from PPV or average cost ripple after component issue will be reflected with the MCTE prefix.
MRCT	Manufacturing Receipt Transaction: Indicates the item was backflushed and consumed in the Manufacturing Receipt Entry window.	Backflushing components during Manufacturing Receipt Entry also consumes inventory. Similar to MCTE, subsequent cost changes will trigger GLTRX batches with the MRCT prefix.
MCLS	Manufacturing Order Closing: Indicates the item was consumed during the closing of a Manufacturing Order (either via the Close process or Quick MOs).	Closing a Manufacturing Order can trigger backflushing of components. If these backflushed components’ costs are subsequently adjusted, the GLTRX batch will have the MCLS prefix.
STCK	Item Stock Count Variance Transaction: Indicates the item was consumed due to a Stock Count adjustment.	Stock count adjustments that decrease inventory quantities can lead to cost adjustments if the item’s cost is later revised. The STCK prefix signifies this scenario.
FSSC	Field Service Series - Service Call: Indicates the item was sold on a Service Call within Field Service.	Selling a part on a service call within Field Service module consumes inventory. Cost changes after the service call will result in GLTRX batches with the FSSC prefix.
FSRMA	Field Service Series - RMA (Return Merchandise Authorization): Indicates the item’s cost change is related to an RMA process in Field Service.	RMAs can involve receiving items back into inventory and potentially scrapping existing inventory. Cost adjustments related to these RMA processes in Field Service can be identified by the FSRMA prefix.
FSRTV	Field Service Series - RTV (Return to Vendor): Indicates the item’s cost change is related to an RTV process in Field Service.	Similar to RMAs, RTVs in Field Service can also trigger cost adjustments if they impact the valuation of inventory or related receipts. The FSRTV prefix indicates this.
FSWO	Field Service Series - Depot Work Order: Indicates the item was used on a Depot Work Order in Field Service.	Using parts on Depot Work Orders in Field Service consumes inventory. Subsequent cost changes will be reflected in GLTRX batches with the FSWO prefix.
PA	Project Accounting Transaction: Indicates the item was consumed via a Project Accounting transaction, such as a PA Inventory Transfer.	Project Accounting transactions, like PA Inventory Transfers, that consume inventory can lead to cost adjustments. The PA prefix indicates that the cost adjustment originated from a Project Accounting context.
POP	Purchase Order Processing Shipment Receipt: Indicates the cost adjustment is related to a Purchase Order Processing shipment receipt, often due to quantity overrides.	If an item’s quantity was overridden during a transaction and later a shipment receipt is processed at a different cost, the POP prefix will indicate that the cost adjustment is linked to this Purchase Order Processing activity.
RECON	Inventory Reconcile Utility: Indicates the outflow being revalued was created by the Inventory Reconcile Utility.	The Inventory Reconcile Utility can create outflow records in specific situations, such as when there aren’t enough quantities in inventory detail tables to support sales quantities. Cost adjustments related to these utility-generated outflows will have the RECON prefix.
CONV	Upgrade Conversion: Indicates the outflow being revalued was created during an upgrade from an older version of Dynamics GP.	Upgrades from older versions may require creating outflow records if receipt records were partially sold at the time of conversion. Cost adjustments for these upgrade-related outflows will have the CONV prefix.
PRCT	In-Transit Transfer Transaction: Indicates the item was overridden on an In-Transit Transfer transaction and later brought in at a different cost.	Similar to POP, if quantities are overridden during In-Transit Transfers and the item is later received at a different cost, the PRCT prefix will indicate the cost adjustment’s origin from this In-Transit Transfer context.

Exception: In scenarios where quantity overrides are permitted in Inventory, and users utilize this functionality, the prefix might not directly correspond to the outflow transaction type as listed above. Instead, it may reference the inflow transaction that brought the quantity back into inventory. This exception is illustrated in the “Inventory Example” section later in this document.

Section 2: Suffix - Identifying the Cost Change Origin¶

The suffix of the reference number provides information about what function or document triggered the change in the cost of the consumed item. It pinpoints the specific event that led to the need for a cost adjustment, providing the why behind the cost revision itself.

Here’s a breakdown of common suffixes you might encounter:

Suffix	Description	Example Scenario
No Suffix	Inventory Adjustment: The absence of a suffix indicates that the cost change was initiated directly through an Inventory Adjustment transaction.	A user manually adjusts the cost of an inventory item using an Inventory Adjustment transaction. This direct cost change will trigger a GLTRX batch with only a prefix and no suffix.
RCTxxxx	Purchasing Document (Receipt): ‘RCT’ followed by numbers indicates the document number of the purchasing document (specifically a receipt) that caused the cost adjustment.	A Purchase Order Processing invoice is matched to a shipment receipt. The invoice cost differs from the receipt cost, creating a Purchase Price Variance (PPV). The suffix ‘RCTxxxx’ will refer to the receipt document number that was impacted by this invoice match.
AdjustedCost	Adjust Cost Utility: This suffix signifies that the cost of the consumed layer was changed using the Adjust Cost Utility within Dynamics GP.	Running the Adjust Cost Utility to recalculate or revise item costs can trigger GLTRX batches if it impacts previously sold or consumed items. The ‘AdjustedCost’ suffix indicates the Adjust Cost Utility as the source of the cost change.
PO	Manually Closed Purchase Order: ‘PO’ suffix indicates that the Purchase Order was manually closed in the Edit PO Status window after being partially or fully received and sold, and then partially invoiced. This specific PO closure scenario can trigger cost adjustments.	A Purchase Order is partially received, items are sold, and then the PO is manually closed via the Edit PO Status window before being fully invoiced. This specific sequence of events can lead to cost adjustments, indicated by the ‘PO’ suffix.

Purchase Order Example: Tracing a GLTRX Batch¶

To illustrate how GLTRX batches and their reference numbers work in practice, consider this Purchase Order example:

1. Purchase Order Creation: A Purchase Order (PO2127) is created for a new item, quantity 1, at a cost of $1.00 per unit.
2. Shipment Receipt: A Shipment Receipt is entered and posted, recording the item receipt at the $1.00 cost. (Note: Receipt document number is RCT1229). At this stage, inventory valuation is $1.00.
3. Sales Transaction: The new item is sold in Sales Order Processing at a cost of $1.00. (Note: Sales transaction document number is STDINV2279). Inventory is now zero for this item.
4. Invoice Matching: The Purchase Order Invoice is entered and matched in Purchase Order Processing for $1.05 per unit. (Note: Invoice receipt document number is RCT1230). This indicates that the actual cost at the time of sale should have been $1.05, not $1.00.

This scenario results in a Purchase Price Variance (PPV) of 5 cents (the difference between the shipment receipt cost and the invoice receipt cost). This PPV is recorded with the Purchase Order Invoice distributions.

Upon posting the Invoice in Purchase Order Processing, Dynamics GP automatically generates a General Ledger cost adjustment within a Financials GLTRX batch. A Purchase Receipts Update Detail Report (PRUD) will print after the Cost Variance Journal, indicating the cost adjustment.

The resulting journal entry in General Ledger will display the following characteristics:

• Source Document: GJ (General Journal)
• Batch ID: Begins with GLTRX
• Reference/Distribution Reference: SALESRCT1230

Breaking down the Reference field:

• Prefix: SALES - Indicates that a Sales Order Processing invoice (STDINV2279) consumed the receipt layer that is now being revalued.
• Suffix: RCT1230 - Indicates that the receipt document number RCT1230 (the Purchase Order Invoice receipt) caused the revaluation.

This example clearly demonstrates how the GLTRX batch and its reference number provide a traceable link back to the originating sales transaction and the purchasing document that triggered the cost adjustment.

Inventory Example: GLTRX from Quantity Override¶

Consider another example focusing on inventory transactions and quantity overrides:

1. Sales Order Invoice (Override): A Sales Order Processing invoice is entered for an item with zero quantity on hand, quantity 1. The system prompts for a quantity override. The override is accepted, and the current cost of $2.00 is used. (Note: Sales transaction document number is STDINV2280).
2. Inventory Increase Adjustment: An increase adjustment is entered into inventory for the same item at a cost of $5.00 and posted. (Note: Inventory Adjustment document number: 00000000000000163).

Upon posting the increase adjustment in Inventory, a General Ledger cost adjustment is automatically created in a Financials GLTRX batch. Again, a PRUD report will be generated.

The journal entry in General Ledger will show:

• Source Document: GJ
• Batch ID: Begins with GLTRX
• Reference/Distribution Reference: IVA00000000000000163

Dissecting the Reference field:

• Prefix: IVA - In this exception scenario (due to the quantity override), the prefix references the inflow transaction (Inventory Adjustment) that brought the quantities back into inventory, rather than the original outflow (Sales Invoice). This is because the override situation technically means the original sale consumed quantities that were not actually available at that time.
• Suffix: None - In this case, there is no suffix, indicating that the cost change was directly initiated by the Inventory Adjustment itself.

This example highlights the exception mentioned earlier, where quantity overrides can alter the prefix interpretation in the GLTRX reference number.

BOM Override Example: GLTRX in Manufacturing¶

Let’s examine a more complex scenario involving Bills of Materials (BOM) and Manufacturing:

1. Item Creation: Two new items are created: “BOM FG” (Finished Good) and “BOM COMPONENT 1”. Both are set up with an Average Perpetual valuation method.
2. BOM Structure: A BOM is created for “BOM FG” consisting of one component: “+BOM Component 1”. “BOM COMPONENT 1” is also defined as a BOM finished good, composed of “+BOM COMPONENT 1 (set to build if necessary)” and “128 SDRAM”.
3. BOM Assembly (Build & Consume): A BOM Assembly transaction is created for “BOM FG”. Since there is no “BOM COMPONENT 1” on hand, the system automatically “builds” one unit of “BOM COMPONENT 1” and then consumes it in the assembly of “BOM FG”. This action creates a “sold” layer for “BOM COMPONENT 1”.
4. Inventory Adjustment (Backdated): An increase adjustment for “BOM COMPONENT 1” is entered at a cost different from the current cost. Crucially, this transaction is backdated to a date prior to the BOM Assembly transaction in step 3.
5. Posting and Reports: When the backdated Inventory Adjustment is posted, a Cost Variance Journal is printed (which will be empty in this scenario). However, the PRUD report printed immediately afterward will show the variance transaction.
6. GLTRX Batch Review: A GLTRX batch is created in General Ledger. The reference number will resemble: BOM00000000000000246.

Analyzing the reference:

• Prefix: BOM - Indicates that a BOM transaction consumed the item.
• Suffix: 00000000000000246 - This number is likely the document number of the Inventory Adjustment transaction that caused the revaluation.

This BOM example demonstrates how GLTRX batches can arise in complex manufacturing scenarios and how the reference number helps pinpoint the contributing transactions.

GLTRX Batch Dates: Period-End Logic¶

The date assigned to transactions within a GLTRX batch is determined by the outflow transaction that is being revalued. Starting with Microsoft Dynamics GP 10 SP2 and GP 9 SP4, a specific date logic was implemented:

If the outflow transaction (e.g., a sale) occurred in a fiscal period prior to the current period, the GLTRX transaction will be dated as the last day of the fiscal period in which the outflow occurred. If the outflow occurred in the current fiscal period, the GLTRX transaction will be dated with the actual transaction date of the event triggering the cost adjustment (e.g., the invoice match date).

Example:

1. Shipment (9/15): A shipment is posted with a date of September 15^th.
2. Sales (9/17, 10/20, 11/5, 12/4): Sales transactions related to that shipment are posted on September 17^th, October 20^th, November 5^th, and December 4^th.
3. Invoice Match (12/12): The invoice match for the shipment is posted on December 12^th at a different cost.

When the purchasing invoice is posted on December 12^th, a GLTRX batch is created in General Ledger. This batch will contain four transactions, one for each sales event. The dates for these transactions will be:

• September Sales (9/17): Dated 9/30 (last day of September - previous period)
• October Sales (10/20): Dated 10/31 (last day of October - previous period)
• November Sales (11/5): Dated 11/30 (last day of November - previous period)
• December Sales (12/4): Dated 12/12 (current period, same as invoice match date)

This date logic ensures that cost adjustments are reflected in the appropriate fiscal periods, even if the cost-changing event occurs in a later period.

Enhancing GLTRX Detail with DEX.INI Switch¶

For more granular detail in GLTRX batches, especially for tracking the originating documents and items involved, a Dex.ini switch can be enabled:

REVALJEINDETAIL=TRUE

Adding this line to the DEX.INI file (located in the Data directory for Dynamics GP 10 and 2010, or the code folder for GP 9.0) will instruct the system to populate additional fields in the GL10001 (GL Transaction Amounts Work) and GL20000 (GL Year-to-Date Transaction Open) tables when creating ripple cost adjustment transactions.

With this switch enabled, the following fields will be populated:

• ORCTRNUM: Contains the originating document number of the outflow transaction (e.g., SOP number, Inventory document number).
• ORMSTRID: Contains the item number involved in the cost change.
• ORMSTRNM: Contains the reference ‘IV Ripple Transaction’.
• ORDOCNUM: Contains the document number of the receipt record in the IV10200 table being updated.

Implementing this Dex.ini switch on all workstations will provide richer data within GLTRX batches going forward, facilitating more detailed analysis and reconciliation.

Purchase Receipts Update Detail (PRUD) Report Enhancement¶

The standard Purchase Receipts Update Detail (PRUD) report provides basic information about cost adjustments, including journal entries, document numbers, and adjustment amounts. However, a modified PRUD report can offer enhanced detail.

The enhanced PRUD report includes additional fields such as:

• Original Cost
• New Cost
• Cost Difference (on a quantity basis)

This expanded detail provides a more comprehensive view of the cost adjustment impact, showing not just the GL impact but also the underlying cost changes.

To utilize the modified PRUD report, a package file needs to be imported into Dynamics GP. This requires Dynamics GP build 9.00.292 or newer. The modified reports are available by Item and Document.

---

Understanding GLTRX batches is essential for maintaining data integrity and accurately interpreting financial transactions within Microsoft Dynamics GP. By recognizing the symptoms, understanding the cause and resolution, and decoding the reference numbers, users can effectively manage and analyze these system-generated cost adjustments.

Do you have any experiences with GLTRX batches in your Dynamics GP environment? Share your insights or questions in the comments below!