Mastering Return Transactions in Dynamics GP: A Comprehensive Guide to Document Types

Table of Contents

Navigating the complexities of return transactions within Microsoft Dynamics GP’s Purchase Order Processing module is essential for maintaining accurate inventory records and financial integrity. This guide meticulously outlines the four primary return transaction document types available: Return, Return w/Credit, Inventory, and Inventory w/Credit. Understanding the specific conditions under which each type should be utilized is paramount for efficient procurement and accounting processes.

This document serves as a detailed resource, describing the prerequisites for each return transaction document type. Furthermore, it provides comprehensive examples for each scenario, illustrating their practical application and impact within Dynamics GP. By mastering these distinctions, users can ensure seamless handling of vendor returns and accurate reflection in the general ledger.

Introduction to Return Transaction Document Types¶

In the realm of purchasing, returns are an unavoidable part of doing business. Whether due to damaged goods, incorrect shipments, or quality issues, the ability to process returns accurately and efficiently is critical. Microsoft Dynamics GP provides a robust framework within its Purchase Order Processing (POP) module to handle these scenarios through distinct document types. These types are designed to address various stages of the procurement cycle, specifically considering whether an invoice has been processed and if the item is still considered part of the company’s active inventory.

The selection of the correct return document type directly influences the financial entries generated and the integrity of your inventory data. An incorrect choice can lead to discrepancies in your general ledger, inaccurate accrued purchases, and misstatements of accounts payable or inventory values. Therefore, a deep understanding of each type’s purpose and conditions is fundamental for all Dynamics GP users involved in purchasing and inventory management. This guide will clarify these nuances, ensuring users can confidently select the appropriate return method for any given situation.

Understanding Purchase Order Processing Returns¶

The Purchase Order Processing module in Microsoft Dynamics GP is a comprehensive system designed to manage the entire purchasing lifecycle, from requisition to payment. Returns are a crucial part of this cycle, enabling businesses to send back goods to vendors under various circumstances. The four document types available for return transactions are carefully structured to accommodate the different states of a purchase order and its associated inventory and invoicing records.

Each return type triggers specific general ledger postings and inventory adjustments, reflecting the transaction’s financial and physical movement. These distinctions are primarily based on two key factors: first, whether the vendor’s invoice for the original shipment has already been posted, and second, whether the returned item has been consumed or removed from the company’s inventory after receipt. Properly identifying these conditions is the first step in selecting the correct return document type.

Return¶

The “Return” transaction document type is specifically designed for scenarios where goods are sent back to a vendor before an invoice has been processed for the original purchase order. This type is used when the inventory item, although received, has not yet been removed from your stock, implying it’s still available on hand. It effectively reverses the initial shipment receipt without impacting accounts payable.

To qualify for a “Return” transaction, three conditions must be met:
* A shipment transaction must have been successfully posted for the purchase order, indicating the goods were physically received into your premises.
* An invoice transaction for that specific purchase order has not yet been entered or posted, meaning there’s no outstanding payable to the vendor for these items.
* The item in the purchase order has not yet been removed from inventory (e.g., sold, consumed, or transferred out), signifying it is still in your available stock.

This document type is crucial for maintaining the accuracy of your accrued purchases and inventory accounts when an invoice has not yet been received. It prevents the creation of unnecessary credit memos and ensures that your financial records correctly reflect the physical movement of goods.

Return w/Credit¶

The “Return w/Credit” transaction document type is utilized when goods are returned to a vendor after an invoice for the original purchase order has been posted. This means that a liability to the vendor has already been recorded in your accounts payable. Similar to the “Return” type, this option is for items that are still physically present in your inventory.

The conditions for using a “Return w/Credit” transaction are as follows:
* A shipment transaction has been posted for the purchase order, confirming the receipt of goods.
* An invoice transaction for the purchase order has also been posted, establishing a payable to the vendor.
* The item in the purchase order has not yet been removed from inventory, indicating it remains in your stock.

Choosing “Return w/Credit” ensures that not only is inventory adjusted correctly, but also that a corresponding credit memo is generated in Payables Management. This credit memo can then be applied against the original invoice, effectively reducing your liability to the vendor and streamlining the financial reconciliation process.

Inventory¶

The “Inventory” transaction document type is employed in situations where a return is necessary, but the item in question has already been removed from inventory. This often occurs when goods have been sold to a customer, consumed in production, or otherwise disposed of, and then subsequently identified as needing to be returned to the vendor. Crucially, this type is used when the original purchase order has not yet been invoiced.

The conditions for using an “Inventory” transaction are:
* A shipment transaction has been posted for the purchase order, acknowledging the initial receipt of goods.
* An invoice transaction has not been entered for the purchase order, meaning no financial liability has been recorded for the original receipt.
* The item in the purchase order has already been removed from inventory, signifying it is no longer in your physical stock.

A notable application of the “Inventory” transaction type is for items in drop-ship purchase orders that were returned by the customer directly. This is applicable if the invoice transaction from your vendor hasn’t yet been matched to the purchase order, allowing for a precise adjustment without affecting existing payables. This type ensures that inventory values are correctly adjusted, even for items that have moved through your system.

Inventory w/Credit¶

The “Inventory w/Credit” transaction document type is the most comprehensive return type, used when goods are returned to a vendor after the original invoice has been posted and the item has already been removed from inventory. This scenario often arises when a customer returns a defective product that was originally purchased and invoiced, and now that product needs to be sent back to the original vendor for a credit.

The specific conditions for utilizing an “Inventory w/Credit” transaction are:
* A shipment transaction has been posted for the purchase order, confirming the initial receipt of goods.
* An invoice transaction has been posted for the purchase order, establishing a financial liability for the goods.
* The item in the purchase order has already been removed from inventory, indicating it is no longer in your stock.

This document type is also applicable for items on drop-ship purchase orders that customers returned after the vendor’s invoice transaction has been posted. It facilitates the creation of a credit memo in Payables Management to offset the vendor invoice, while simultaneously making the necessary adjustments to inventory and cost of goods sold accounts, ensuring full financial and inventory reconciliation.

Comparative Overview of Return Transaction Types¶

To further clarify the distinctions, let’s look at a summary table highlighting the key conditions and primary impacts of each return type:

Document Type	Shipment Posted?	Invoice Posted?	Item in Inventory?	Primary Financial Impact
Return	Yes	No	Yes	Reverses Accrued Purchases & Inventory
Return w/Credit	Yes	Yes	Yes	Creates Credit Memo (AP) & Reduces Inventory
Inventory	Yes	No	No	Reverses Accrued Purchases & Inventory (after re-entry to inventory via sales return)
Inventory w/Credit	Yes	Yes	No	Creates Credit Memo (AP) & Reduces Inventory (after re-entry to inventory via sales return)

This table provides a quick reference for determining the appropriate return document type based on the status of your purchase order and inventory.

Examples of Return Transaction Document Types¶

These examples illustrate the practical application of each return document type. It is important to note that, for simplicity, no cost variances are considered in these scenarios. The focus remains on the primary general ledger entries and inventory adjustments.

Examples of Return¶

Consider a scenario where a user enters a purchase order for 10 units of an item, with a unit cost of $150. The vendor ships these 10 units, and a shipment receipt transaction is posted for $1,500. This action increases the item quantity in Inventory by 10 units and creates the following general ledger entries:

• Debit: Inventory $1,500
• Credit: Accrued Purchases $1,500

One day later, before the invoice arrives, it is discovered that 3 of the 10 units must be returned for replacement due to damage. None of the units from this shipment have been sold or used.

To process this return, the user accesses the Returns Transaction Entry window and selects the Return transaction document type. The transaction number of the original shipment is entered in the Receipt No. field, and 3 is entered in the Quantity Returned field. Upon posting the Return document, a transaction is generated with the following general ledger entries:

• Debit: Accrued Purchases ($450 = 3 units x $150/unit)
• Credit: Inventory ($450 = 3 units x $150/unit)

This reverses the accrued purchase and inventory value for the returned units. If replacement units are expected, a new line item must be added to the original purchase order with a Quantity Ordered equal to the units being replaced. This ensures the system tracks the pending delivery of the new items correctly.

Examples of Return w/Credit¶

Let’s use a similar scenario: a purchase order for 10 units at $150 each is entered. A shipment receipt transaction for all 10 units ($1,500) is posted, increasing Inventory by 10 units and generating these journal entries:

• Debit: Inventory $1,500
• Credit: Accrued Purchases $1,500

The next day, the vendor’s invoice arrives and is entered and matched to the shipment in Purchase Order Processing. Posting this invoice creates the following general ledger entries:

• Debit: Accrued Purchases $1,500
• Credit: Accounts Payable $1,500

Subsequently, it’s discovered that all 10 units in the shipment are damaged and must be returned for replacement. No units have been sold from this shipment.

To handle this, the user returns the 10 units in the Returns Transaction Entry window, selecting the Return w/Credit transaction document type. The original shipment’s transaction number is entered in the Receipt No. field. Posting this Return w/Credit document automatically creates a credit memo in Payables Management. Concurrently, a transaction with the following general ledger entries is posted:

• Debit: Accounts Payable ($1,500 = 10 units x $150/unit)
• Credit: Inventory ($1,500 = 10 units x $150/unit)

The credit memo in Payables Management should then be applied to the original invoice using the Apply Payables Documents window, effectively reducing the amount owed to the vendor. If replacements are anticipated, a new line item is added to the original purchase order with the Quantity Ordered set to the number of units being replaced.

Examples of Inventory¶

Imagine a purchase order for 10 units of an item at $150 each. A shipment receipt transaction for 10 units ($1,500) is posted, increasing Inventory by 10 units and resulting in these general ledger entries:

• Debit: Inventory $1,500
• Credit: Accrued Purchases $1,500

The day after the shipment, all 10 units are sold to a customer. An invoice is posted in the Sales Transaction Entry window, creating the following journal entries (assuming a selling price of $202.50 per unit):

• Debit: Cost of Goods Sold (COGS) $1,500
• Debit: Accounts Receivable $2,025
• Credit: Inventory $1,500
• Credit: Sales $2,025

The following day, two of the sold units are reported as defective and must be returned to the vendor. Crucially, the original purchase order for these items has not yet been invoiced by the vendor in Purchase Order Processing.

First, a return transaction is posted in the Sales Transaction Entry window for the two defective units (unit cost $150, unit price $202.50). This increases quantities in Inventory for the item and creates the following general ledger transaction:

• Debit: Inventory ($300 = 2 units x $150/unit)
• Debit: Sales ($405 = 2 units x $202.50/unit)
• Credit: COGS ($300 = 2 units x $150/unit)
• Credit: Accounts Receivable ($405 = 2 units x $202.50/unit)

Next, the user returns the two defective units to the vendor in the Returns Transaction Entry window using the Inventory transaction document type. The document number of the sales return is entered in the Receipt Number field. It is crucial to change the inventory account for this purchasing return to match the inventory account used in the sales return, and similarly, adjust the accrued purchases account to the one used in the original shipment receipt.

Upon posting the Inventory document, a transaction is created with these entries:

• Debit: Accrued Purchases ($300 = 2 units x $150/unit)
• Credit: Inventory ($300 = 2 units x $150/unit)

If replacement units are expected, a new line item is added to the original purchase order with the Quantity Ordered equal to the units being replaced. When the original purchase order is viewed, the Quantity Received field still displays 10 units, but the Quantity Invoiced field now shows eight units. The purchase order line’s status will display as Received. For the replacement line item, the Quantity Received and Quantity Invoiced fields display two units, and its status shows Closed.

Finally, when the purchase order status changes to “Closed,” an Edit PO journal entry (EDTPO) is created, which automatically reverses the general ledger effect of the original shipment for any units received but not yet invoiced. In this specific example, the EDTPO journal would contain:

• Debit: Accrued Purchases $300
• Credit: Inventory $300

Since the Accrued Purchases account has already been correctly reversed by the Inventory return document in Purchase Order Processing, this system-generated Edit PO journal entry must be manually deleted from the general ledger to prevent double-reversal. This step is critical for maintaining accurate financial records.

Examples of Inventory w/Credit¶

Consider a purchase order for 10 units of an item at $150 each. A shipment transaction for these 10 units ($1,500) is posted, increasing Inventory by 10 units and posting the following journal entry:

• Debit: Inventory $1,500
• Credit: Accrued Purchases $1,500

The day after the shipment, all 10 units are sold to a customer. An invoice is posted in the Sales Transaction Entry window, creating these distributions (assuming a selling price of $216.00 per unit):

• Debit: COGS $1,500
• Debit: Accounts Receivable $2,160
• Credit: Inventory $1,500
• Credit: Sales $2,160

Two days later, an invoice for the 10 units is posted in Purchase Order Processing, leading to the following general ledger journal entry:

• Debit: Accrued Purchases $1,500
• Credit: Accounts Payable $1,500

The next day, two of the sold units are reported as defective and must be returned to the vendor.

First, a return transaction is posted in the Sales Transaction Entry window for the two defective units (unit cost $150, unit price $216.00). This action increases inventory quantities for the item and creates a general ledger transaction with these distributions:

• Debit: Inventory ($300 = 2 units x $150/unit)
• Debit: Sales ($432 = 2 units x $216.00/unit)
• Credit: COGS ($300 = 2 units x $150/unit)
• Credit: Accounts Receivable ($432 = 2 units x $216.00/unit)

Next, the two defective units are returned to the vendor in the Returns Transaction Entry window, using the Inventory w/Credit transaction type. The sales return document number is entered in the Receipt Number field. It is important to change the inventory account to the one used in the original sales return transaction, and the payables account to the accounts payable account from the purchasing shipment transaction.

Upon posting this transaction, a credit memo is automatically created in Payables Management. Additionally, a general ledger transaction with the following distributions is created:

• Debit: Accounts Payable ($300 = 2 units x $150/unit)
• Credit: Inventory ($300 = 2 units x $150/unit)

In the Apply Payables Documents window, the return credit memo is then applied to the original vendor invoice, reducing the amount owed. If replacement units are expected, a new line item must be entered in the original purchase order.

After processing the return, the Purchase Order (PO) status might automatically change. If further actions, such as adding new line items for replacements, are required, the PO status may need to be manually adjusted. To modify the PO status:

1. Navigate to the Transactions menu, point to Purchasing, and then select Edit Purchase Orders.
2. In the PO Number field, enter the relevant purchase order number.
3. From the Purchase Order Status list, select Change Order.
   • Note: A purchase order on hold cannot have its status changed to Received, Closed, or Canceled until the hold is removed. Similarly, if a purchase order has sales commitments, its status cannot be changed to Received, Closed, or Canceled.
4. Select Process to apply the status changes.

This comprehensive approach ensures that both inventory and financial records are accurately updated, reflecting the complex flow of goods and funds when returns involve items already sold and invoiced.

---

We hope this detailed guide on mastering return transactions in Dynamics GP has been informative and helpful. Understanding these document types is crucial for maintaining accurate inventory and financial records. Do you have any further questions or specific scenarios you’d like to discuss? Share your thoughts and experiences in the comments below!