General Ledger Overview

Purpose: The General Ledger Overview describes how the system captures General Ledger transactions in an interface table that you can download to a third-party General Ledger product.

Types of transactions: These are examples of the types of transactions that are captured in the General Ledger Interface table so you can later post them to the General Ledger:

• Sales (billing)

• Inventory

• Refunds

• Purchase order receipts

• Cash receipts

Softcoded G/L accounts: All General Ledger account numbers are user-defined (softcoded). This allows you to duplicate the accounting structure you use with your current General Ledger application.

In this topic:

• Posting Changes to Inventory Value

• GLINVEN Process G/L Inventory Periodic Function

• Division Table

• Selecting the Division for Inventory Transactions

• Item Table

• Warehouse Table

• Inventory Transaction Table

• Item Class Table

• Amount of Posting for Inventory

• A = Adjustment

• C = Customer Item Return

• G = Item to Item Transfer

• I = Issue

• O = On-Hand

• P = Physical Inventory

• R = Receipt

• T = Transfer

• V = Return to Vendor

• * = Change FIFO Cost

• * = Change Average or Standard Cost

• User-defined Inventory Transaction Codes

• Posting Sales

• Posting Gross Sales

• Posting Net Sales

• Posting Merchandise Sales and Discounts for Price Overrides

• Deferred Liability for Prepaid Orders

• Deferred Liability for Prepaid Memberships

• Credit Liability for Coupons

• Deposits

• Posting Refunds

• How Pay Types Control Refunds

• Billing Returns

• Refunding Overpayments by Cash/Check

• Refunding Overpayments for Coupons & Merchandise Credits

• Refunds in Original Pay Type for Returns

• Refunds in Alternate Pay Type

• Writing Off Refunds

• Canceling Refunds

• Voiding/Reinstating Refund Checks

Posting Changes to Inventory Value

Purpose: Changes to inventory resulting from inventory transactions post to the General Ledger Interface table when you run the GLINVEN periodic function so that you can track the value of your inventory.

Setup: You can track inventory value at the warehouse and/or item level.

The inventory transaction code used determines which offsetting G/L account is affected by the transaction. However, you can enter override cost of goods sold account numbers at the item class or division level for posting shipments and returns for orders.

Note: No one-sided transactions will post to the General Ledger; you need to set up the G/L account numbers plus the corresponding offsetting G/L accounts.

GLINVEN Process G/L Inventory Periodic Function

When you perform an inventory transaction, the system creates a record in the Item Transaction History table and sets the GL Process Date to 0 indicating the inventory update has not been posted to the general ledger.

Run the GLINVEN periodic function (program name PFR0099) to post the inventory updates to the general ledger. The periodic function:

• Looks at the GL Process Date field in the Item Transaction History table to determine which inventory updates to post to the general ledger. The function selects records whose GL Process Date is 0.

• Looks at the setting of the Capture General Ledger Detail (E71) system control value to determine whether to post inventory updates to the General Ledger Detail table.

• Uses the item transaction history date as the general ledger transaction date.

Run this periodic function as part of your daily process. When completed, the function updates the GL Process Date field for the item transaction history records included in the general ledger postings to the current date.

Division Table

Most general ledger numbers are defined in the Division table. See Working with Divisions (WDIV).

Selecting the Division for Inventory Transactions

Enter a valid division code in the Default Division for Inventory Transactions (C17) system control value to post inventory transactions to the General Ledger.

Important: No inventory transactions post to the General Ledger if you leave this System Control value blank.

Override division for warehouse: If you specify a Division for a warehouse, the system uses this division, rather than the Default Division for Inventory Transactions (C17), for posting inventory transactions to the General Ledger.

Use division from order? To use the division associated with the source code on an order to post the cost of goods sold for sales and returns, set the Post Inventory G/L Transactions Using Source Code Associated with Order (F81) system control value to Y. If you also set the Post Sales G/L Using Division at Order Line Source Code (F17) system control value to Y, the system uses the division associated with the source code, if any, at the order detail line level.

Item Table

Enter a valid General Ledger account number in the Inv G/L # (Inventory general ledger account number) field in the Item table if you want to track inventory value at the item level; otherwise, leave this field blank and complete the Inventory value G/L # in the Warehouse table.

The system uses the G/L number defined for an item, if one exists; if not, it will use the G/L number defined for the warehouse in which the item is stored.

Warehouse Table

Enter a valid General Ledger account number in the Inventory value G/L #field in the Warehouse table to track the inventory value for all items stored in this warehouse.

You can set up different G/L accounts for each different type of warehouse you set up, such as a main, defective, or sample warehouse.

Also, specify a Division for a warehouse to use this division, rather than the Default Division for Inventory Transactions (C17), for posting inventory transactions to the General Ledger.

Inventory Transaction Table

Inventory transaction codes are used by the system to process various transactions automatically without any user interaction.

For example, when inventory is received through Purchase Order Receipts, the system uses the R (Receipt) inventory transaction code when updating inventory.

The G/L# (General Ledger account number) defined here is used as the offsetting account number to the G/L account # defined for the item or warehouse affected by the inventory transaction. Make sure that you specify a general ledger account number for each inventory transaction code in order to make sure that all of your general ledger postings take place correctly.

Note: You can override the G/L account # for the inventory transaction code by entering an override number when you work with inventory transactions, or by defining override account numbers for certain transactions that take place "behind the scenes."

Item Class Table

Use Working with Item Classes (WICL) to define general ledger account numbers that override the account numbers you define for the division.

The account numbers are used to post sales, discounts, returns, and the cost of goods for sales and returns, respectively.

Amount of Posting for Inventory

The cost that the system posts to the General Ledger for inventory transactions depends on the transaction type and the setting of the Costing Method (A25) system control value:

• Receipt (R) costs: if you are using average costing or FIFO costing, the system uses the cost at purchase order receiving; if you are using standard costing, the system uses the standard cost.

• Transfers (T) and Vendor Returns (V) through Vendor Charge backs: the system uses the cost from the Vendor charge back.

• For all other inventory transactions types, the system posts the standard or average cost from the SKU table or the extended FIFO cost from the FIFO layers to the General Ledger, depending on the costing method defined in the System Control table.

Required codes: At system setup, you can define these inventory transaction codes using Work with Inventory Transaction Codes (WITC) (You can also define your own inventory transaction codes):

Code	Description	Effect on Inventory Levels
A	Adjustment	Used in inventory transactions to increase on-hand if positive quantity is entered; decreases on-hand if negative quantity is entered.
C	Customer Return	Used by the system when processing return merchandise via the Return Authorization module or Order Maintenance. Return transactions will always increase the on-hand quantity in the specified warehouse as long as you select the Affect inventory field when processing the return. Important: If you do not specify an account number for the customer return (C) transaction code, then the cost of goods sold will not post to the general ledger when you receive a return. See Work with Inventory Transaction Codes (WITC).
G	Item to Item Transfer	Optional: Used in inventory transactions to increase on-hand for the target item and decrease the on-hand for the source item.
I	Issue	Used by the system to decrease on-hand for confirmed shipments.
M	Make Up Finished Good	Used in inventory transactions to increase on-hand quantity for the finished good item and decrease on-hand for the components.
O	Reset On-hand	Resets the on-hand quantity to the entered value.
P	Physical	Used by the physical inventory update program when adjusting on-hand based on physical counts entered. If the count is greater than on-hand, on-hand will be increased. If the count is less than on-hand, then on-hand will be decreased.
R	Receipt	Used in the purchase order receipts program for merchandise received. Increments the on-hand.
T	Transfer	Used in inventory transactions to increase on-hand in "to" location and decreases the on-hand in "from" locations.
V	Return to Vendor	Used in inventory transactions to decrease on-hand amount if positive quantity is entered; increases on-hand if negative quantity is entered.
*	Change FIFO cost	Optional: Used to change the unit cost of a FIFO layer.

A = Adjustment

This inventory transaction code is used to increase or decrease the quantity on-hand for an item in a particular location in the warehouse.

Use a positive transaction quantity to increase the on-hand quantity.

Use a negative transaction quantity to decrease the on-hand quantity.

For the A (Adjustment) type inventory transaction code, if the +/- (Add to/Subtract from inventory) flag is positive (+), the transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in Item or Warehouse table	Credit G/L account in Item or Warehouse table
Credit G/L account defined for the Inventory Transaction Code	Debit G/L account defined for the Inventory Transaction Code

These transactions are reversed if the Effect on inventory flag for this inventory transaction code is negative (-).

C = Customer Item Return

The system uses this inventory transaction code to increase inventory when an item return is entered through Order Entry or Order Maintenance.

Important: If you do not specify an account number for the customer return (C) transaction code, then the cost of goods sold will not post to the general ledger when you receive a return. See Work with Inventory Transaction Codes (WITC).

The transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit the G/L account in Item or Warehouse table
Credit the Cost good return G/L account defined for the item's item class, if any; otherwise, credit the Cost of goods return G/L account defined for the division; otherwise, credit the G/L account defined for the inventory transaction code

Non inventory and dropship: In addition, the system makes these postings if the Create Item Transaction History for Non-Inventory Items (E39) system control value is selected:

Effect on Inventory is Positive (+)	Effect on Inventory is Negative (-)
Debit the G/L account in Item or Warehouse table
Credit the Cost good return G/L account defined for the item's item class, if any; otherwise, credit the Cost of goods return G/L account defined for the division; otherwise: • Dropship item: credit the G/L account defined for the inventory transaction code • Noninventory item: do not post

Which division? See Selecting the Division for Inventory Transactions for more information on how the system determines which division to use for posting the cost of goods for issue transactions.

G = Item to Item Transfer

Use this inventory transaction code to transfer the inventory of one item to another item code. When you make this kind of transfer, you post the difference in the "from" item and "to" item costs (the markup) to the general ledger as well.

Note: This inventory transaction is not available if you use FIFO Costing.

The transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in Item or Warehouse table for the transfer “to” item (using “to” item cost)
Credit G/L account defined in Item or Warehouse table for the transfer “from” item (using “from” item cost)
Debit the Item to Item Transfer G/L account from the Division table for the markup (difference between the “from” item and “to” item costs)

Note: To achieve these results, the system uses the G/L # defined for the G inventory transaction code as a work account, but the end result to this G/L account is a wash.

I = Issue

The system uses this code to decrease inventory when an item is confirmed as "shipped" via an upload from the PC manifest system or through manual confirmation. This is also known as a "sale."

The quantity is always positive.

The Effect on inventory flag for this transaction code is negative (-). The transactions posted to inventory are:

	Effect on Inventory is Negative (-)
	Debit the Cost good sold G/L account defined for the item's item class, if any; otherwise, debit the Cost of goods sold G/L account defined for the division, if any; otherwise, debit G/L account defined for the inventory transaction code.
	Credit G/L account defined in the Item or Warehouse table

Non inventory and dropship: In addition, the system makes these postings if the Create Item Transaction History for Non-Inventory Items (E39) system control value is selected:

	Effect on Inventory is Negative (-)
	Dropship item: Debit the Cost good sold G/L account defined for the item's item class, if any; otherwise, debit the Drop ship C.O.G. G/L account defined for the division. Note: If both the Drop ship C.O.G. and the Drop ship C.O.G. offset G/L accounts for the division are not defined, the transaction will not post to the general ledger. Noninventory item: Debit the Cost good sold G/L account defined for the item's item class, if any; otherwise, debit the Non-inventory COGS G/L account defined for the division. Note: If both the Non-inventory COGS and Non-inventory COGS offset G/L accounts for the division are not defined, the transaction will not post to the general ledger.
	Dropship item: Credit the Drop ship C.O.G. offset G/L account for the division. Note: If both the Drop ship C.O.G. and the Drop ship C.O.G. offset G/L accounts for the division are not defined, the transaction will not post to the general ledger. Noninventory item: Credit the Non-inventory COGS offset G/L account defined for the division. Note: If both the Non-inventory COGS and Non-inventory COGS offset G/L accounts for the division are not defined, the transaction will not post to the general ledger.

Which division? See Selecting the Division for Inventory Transactions for more information on how the system determines which division to use for posting the cost of goods for issue transactions.

M = Make Up Finished Good

The system uses this code to increase the inventory of the finished good and decrease the inventory of its component items. See Finished Good Work Order Processing (WWOR).

The transaction quantity for the finished good item is positive.

The transaction quantity for the component items is negative.

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in Item or Warehouse table	Credit G/L account in Item or Warehouse table
Credit G/L account defined for the Inventory Transaction Code	Debit G/L account defined for the Inventory Transaction Code

O = On-Hand

You can use this code when entering inventory transactions to reset the on-hand quantity to the entered value. For example, enter 20 to reset the on-hand quantity for the item/location to 20.

The transaction quantity is negative if the on-hand quantity you enter is less than the on-hand quantity was before you reset it.

If the Effect on inventory flag for this inventory transaction code is positive (+), the transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in the Item or Warehouse table	Credit G/L account in Item or Warehouse table
Credit G/L account defined for the inventory transaction code	Debit G/L account defined for the inventory transaction code

These transactions are reversed if the Effect on inventory flag for this inventory transaction code is negative (-).

Note: This inventory transaction is not available if you use FIFO Costing.

P = Physical Inventory

The system uses this code to adjust on-hand counts for an item after a physical inventory table is processed.

The quantity is negative if the on-hand quantity counted is greater than the actual on-hand quantity maintained on the system.

If the Effect on inventory flag for this inventory transaction code is positive (+), the transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in the Item or Warehouse table	Credit G/L account in Item or Warehouse table
Credit G/L account defined for the inventory transaction code	Debit G/L account defined for the inventory transaction code

These transactions are reversed if the Effect on inventory flag for this inventory transaction code is negative (-).

R = Receipt

The system uses this code to increase inventory when you receive new inventory through PO Receipts.

The quantity is always positive.

The Effect on inventory flag for this inventory transaction code is positive (+).

The transactions posted to inventory are:

Effect on Inventory is Positive (+)
Debit G/L account defined in the Item or Warehouse table
Credit G/L account defined for the purchase order detail line or the inventory transaction code

Posting additional charges: If the Post Purchase Order Additional Charges to General Ledger (G30) system control value is selected, the system posts any purchase order estimated additional charges, purchase order vendor item additional charges, and purchase order receipt control charges to a separate general ledger account number when you receive a purchase order. The system posts the charges to the general ledger account number defined for each additional charge in Working With PO Additional Charges (WPAC).

The transactions posted to inventory are:

Effect on Inventory is Positive (+)
Debit G/L account defined for the purchase order detail line or inventory transaction code
Credit G/L account defined for each purchase order additional charge

T = Transfer

This inventory transaction code is used to move inventory from one location to another or from one warehouse to another.

Use a positive transaction quantity to transfer the on-hand quantity.

For the T (Transfer) type inventory transaction code, if the Effect on inventory flag is positive (+), the transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in Item or Warehouse table for the transfer “to” warehouse	Credit G/L account in Item or Warehouse table for the transfer “to” warehouse
Credit G/L account defined in Item or Warehouse table for the transfer “from” warehouse	Debit G/L account defined in the Item or Warehouse table for the transfer “from” warehouse

Note: To achieve these results, the system uses the G/L # defined for the T inventory transaction code as a work account, but the end result to this G/L account is a wash.

These transactions are reversed if the Effect on inventory flag for this inventory transaction code is negative (-).

V = Return to Vendor

The system uses this code to decrease the on-hand quantity of an item returned to the vendor.

The quantity entered is typically positive (+) and the Effect on inventory flag for this inventory transaction code is typically negative (-).

If the Effect on inventory flag is set to (-), the transactions posted to inventory are:

Effect on Inventory is Positive (+)	Effect on Inventory is Negative (-)
	Credit G/L account defined for the inventory transaction code
	Debit G/L account defined in the Item or Warehouse table

Reverse the transactions above if the Effect on inventory flag for this inventory transaction code is positive (+). Also, enter the quantity as a negative amount.

* = Change FIFO Cost

The system uses this code to increase or decrease total inventory valuation to reflect a change to the unit cost of a FIFO layer if you use FIFO costing.

For example, you receive 10 units of an item at $1.00 each: the extended cost of the FIFO layer is $10.00, and this dollar amount posts to the General Ledger Interface table for the R inventory transaction. Later, you determine that the correct unit cost of the item is $1.50. You enter this change in cost through Using FIFO Cost Layer Inquiry (WFCF). If there are still 10 units of the item on-hand for the FIFO layer, the new extended cost is $15.00, an increase of $5.00 in inventory valuation. This $5.00 difference posts to the general ledger.

Unlike the other inventory transaction codes, the * transaction code does not affect the total on-hand quantity of an item in a location.

Effect on Cost is Positive (+)	Effect on Cost is Negative (-)
Debit G/L account defined in the Item or Warehouse table	Credit G/L account defined in the Item or Warehouse table
Credit G/L account defined for the inventory transaction code	Debit G/L account defined for the inventory transaction code

When are FIFO cost changes posted to the general ledger? The system posts a FIFO cost change to the general ledger when you change the cost through Using FIFO Cost Layer Inquiry (WFCF). The system does not post a FIFO cost change to the general ledger when you run the GLINVEN Process G/L Inventory Periodic Function or change the FIFO cost of an item/SKU in Work with Items/SKUs (MITM).

* = Change Average or Standard Cost

The system uses this code to increase or decrease total inventory valuation to reflect a change in an item/SKUs standard or average cost if the Costing Method (A25) system control value is set to STANDARD or AVERAGE.

For example, if you use the Work with Items/SKUs menu option (Fast path = MITM) to change the standard cost of an item from $10.00 to $9.00, the system multiplies the $1.00 difference by the total on-hand quantity of the item/SKU in all warehouses to determine the total difference in inventory valuation. If there are 100 units of the item/SKU on-hand, the system posts the difference of $100.00 to the general ledger.

This posting takes place when you:

• change the cost of an item/SKU in Work with Items/SKUs (see Performing Initial Item Entry (MITM))

• update standard cost based on the Vendor Item price and additional Vendor Item Additional Charges (see Updating Standard Cost)

• update the cost of a finished good item (see Updating the Cost of a Finished Good)

This general ledger posting takes place only if the * inventory transaction code has been set up through Work with Inventory Transaction Codes (WITC). Also, unlike with other inventory transaction codes, the system does not write an Item Transaction History record when you change an item’s standard or average cost, although the * transaction code is indicated in the General Ledger Interface Detail record. The system determines the general ledger account numbers for this transaction using the same hierarchy as with other inventory transactions.

Effect on Cost is Positive (+)	Effect on Cost is Negative (-)
Debit G/L account defined in the Item or Warehouse table	Credit G/L account defined in the Item or Warehouse table
Credit G/L account defined for the inventory transaction code	Debit G/L account defined for the inventory transaction code

User-defined Inventory Transaction Codes

You can define your own inventory transaction codes to better track inventory adjustments. The Effect on inventory flag controls how the General Ledger Interface table is updated.

If the Effect on inventory flag is positive (+), the G/L update should always debit the inventory value and credit the offsetting account (defined for this inventory transaction code). The transactions posted to inventory are:

Transaction Quantity is Positive (+)	Transaction Quantity is Negative (-)
Debit G/L account in the Item or Warehouse table	Credit G/L account in Item or Warehouse table
Credit G/L account defined for the inventory transaction code	Debit G/L account defined for the inventory transaction code

Reverse these transactions if the Effect on inventory flag is negative (-).

Posting Sales

Hierarchy: The system uses this hierarchy when posting sales and returns to the General Ledger:

1. Item Class Table

2. Division Table

Sales posting
	Debit	Credit
G/L Account:	Sales G/L #	Sales G/L #
Table:	Pay Type G/L table	Item Class table or Division table

Sales posting for a deferred payment plan
	Debit	Credit
G/L Account:	Sale/Deferred G/L #*1	Sales G/L #
Table:	Pay Type G/L table	Item Class table or Division table

Sales posting for an installment payment plan
	Debit	Credit
G/L Account:	Sale/Installment G/L #2	Sales G/L #
Table:	Pay Type G/L table	Item Class or Division table

Returns posting for a deferred payment plan
	Debit	Credit
G/L Account:	Returns G/L #	Return/Deferred G/L #**
Table:	Item Class table or Division table	Pay Type G/L table

Returns posting for an installment payment plan
	Debit	Credit
G/L Account:	Returns G/L #	Return/Installment G/L #***
Table:	Item Class table or Division table	Pay Type G/L table

*The system uses the Sales G/L # if the Returns G/L # for the division or pay type is blank.

**The system uses the Sale/Deferred G/L # if the Return/Deferred G/L # for the pay type is blank. If the Sale/Deferred G/L # is blank, the system uses the Returns G/L # for the pay type.

***The system uses the Sale/Installment G/L # if the Return/Installment G/L # for the pay type is blank. If the Sale/Installment G/L # is blank, the system uses the Returns G/L # for the pay type.

Note: The system posts merchandise sales, merchandise discounts, returns and discount returns to the division associated with the source code on the order detail line if the Post Sales G/L Using Division at Order Line Source Code (F17) system control value is selected. See that system control value for more information.

Posting Gross Sales

You must define sales and discount G/L #'s for each item class or division to post both gross sales and discount.

If a discount G/L # is defined, the system posts a gross sales value to the sales G/L # and the discount to the discount G/L #.

	Debit (sales)	Credit (sales and discount)	Debit (discount)
G/L Account:	Sales G/L # (post net merchandise sales amount)	Sales G/L # (post gross merchandise sales amount)	Discount G/L # (post the discount amount)
Table:	Pay Type G/L table	Item Class or Division table	Item Class or Division table

You must define a discount G/L number for the item class if you want to post gross sales at the item class level (a sales G/L # is defined for each item class); otherwise, the system posts gross sales for the item class and the discount for the division.

Posting Net Sales

The system posts net sales to the sales G/L # defined for the item class or division if you define only a sales G/L # for the item class or division.

Posting Merchandise Sales and Discounts for Price Overrides

At billing, the system posts merchandise sales and discounts as follows, depending on whether there is a price override for the order detail line:

No price override:

• Credit the offer price to Merchandise sales.

• Debit the discount amount to Merchandise discount.

Price override that is not set to override the item/offer price:

• If there is an offer price:

• Credit the offer price to Merchandise sales.

• Debit the difference between the offer price and the selling price (including any additional discounts) to Merchandise discount.

• If there is no offer price:

• Credit the entire selling price (reflecting any additional discounts) to Merchandise discount.

Price override that is set to override the item/offer price:

• Credit the price override amount that you enter in order entry to Merchandise sales.

• Debit the difference between the price override entered and the selling price (resulting from any additional discounts) to Merchandise discount.

 

Example:

Discount	G/L Merchandise Postings (Offer Price = $1.00)	G/L Merchandise Postings (No Offer Price)
No price override:
no	sales ($1.00)	N/A
10%	sales ($1.00) discount $.10	N/A
Override price to $.75, Override item/offer unselected:
no	sales ($1.00) discount $.25	discount ($.75)
10%	sales ($1.00) discount $.32	discount ($.68)
Override price to $.75, Override item/offer selected:
no	sales ($.75)	sales ($.75)
10%	sales ($.75) discount $.07	sales ($.75) discount $.07

Note: The setting of the Override item offer price field has no effect on orders you receive through the order API. If there is a price override reason code in the new order message, the system always processes these orders as if the flag is unselected.

For more information: See Overriding the Item/SKU Offer Price.

Deferred Liability for Prepaid Orders

These transactions post during Order Async when you accept a prepaid order (paid by cash or check). This posting establishes your liability for shipping the item to the customer.

	Debit	Credit
G/L Account:	A/R Cash G/L #	Sales G/L #
Table:	Bank table (use the default bank from the Default Bank for Cash Posting from Order Entry (D17) value)	Pay Type G/L table

Important: These postings occur only if the Deferred Liability Cash Post Method (C48) system control value is set to ORDER (Order Entry).

Deferred Liability for Prepaid Memberships

These transactions post during Order Async when you apply cash to a membership. You can use Memberships to generate periodic orders to customers. This posting establishes your liability for any orders you have not yet created for the membership.

	Debit	Credit
G/L Account:	A/R Cash G/L	Membership Deferred Liability G/L #
Table:	Bank table (use the default bank from the Default Bank for Cash Posting from Order Entry (D17) System Control value)	Division G/L table

Subsequently, when you create an order for a prepaid membership, the system posts these transactions:

	Debit	Credit
G/L Account:	Membership Deferred Liability G/L #	Sales G/L #
Table:	Division G/L table	Pay Type G/L table

Important: These postings occur only if the Deferred Liability Cash Post Method (C48) system control value is set to ORDER (Order Entry).

Credit Liability for Coupons

These transactions post during Order Async when you accept an order with a coupon payment type. This posting enables you to track your credit liability.

	Debit	Credit
G/L Account:	Refund G/L #	Sales G/L #
Table:	Pay Type G/L table	Pay Type G/L table

This posting occurs only if the Post Coupon Liability to G/L for New Orders (D52) system control value is selected.

Deposits

These transactions post when a deposit if received as confirmed from the deposit service.

Positive transactions
	Debit	Credit
G/L Account:	A/R Cash G/L	Sales G/L #*
Table:	Bank for A/R Credit Card Deposits system control value	Pay Type table

The system uses the Sale/Deferred G/L # if the deposit is associated with a deferred payment plan. The system uses the Sale/Installment G/L # if the deposit is associated with an installment payment plan.

Negative transactions
	Debit	Credit
G/L Account:	Returns G/L*	A/R Cash G/L
Table:	Pay Type table	Bank for A/R Credit Card Deposits system control value

The system uses the Return/Deferred G/L # if the credit is associated with a deferred payment plan. The system uses the Return/Installment G/L # if the credit is associated with an installment payment plan.

Note: The system does not post a transaction to the general ledger during deposits for stored value card pay types; see Stored Value Card General Ledger Postings.

Posting Refunds

Purpose: The General Ledger Interface table is updated automatically to reflect that a refund has been issued. The system generates refunds because of:

• Overpayments: when the amount paid on a prepaid order (cash, check, coupon, or gift certificate) is greater than the order total.

• Returns: when a customer item return is entered through Order Entry (if the original order is no longer on the system), Order Maintenance, or Return Authorizations.

• Order Maintenance: when you cancel an item from a prepaid order or you cancel the order entirely, when you add an additional charge credit (to reimburse the customer for some type of expense, such as long-distance telephone charges), when you sell out an item, or when you issue a discount (for an item that has gone on sale since the customer ordered it).

• Additional menu options: when you use the Processing Auto Soldout Cancellations (MASO), the Working with Backorders Pending Cancellation (WBPC), or Processing Item Substitutions (PSUB), you can sell out or cancel backordered items.

For refunds generated as a result of an overpayment on a prepaid order, it is assumed that the G/L posting to post the initial deferred liability was made either from Order Async or through Working with Cash Receipts (WCRT) (depending on the value in the Deferred Liability Cash Post Method (C48) system control value).

For refunds generated from an item return or Order Maintenance transaction (item or order cancellation), it is assumed that the G/L posting made in billing will establish the refund liability.

How Pay Types Control Refunds

The type of refund issued by the system is controlled by the pay type on the order. The system will try to issue the refund in the same form of payment used to bill the order. For example, if the order was billed against a cash pay type, the system will generate a refund check.

You can, however, define an alternate refund type for each pay type. For example, you can define an alternate refund type for merchandise credits if you accept this as payment, but do not want to issue this type of refund. The system will create a refund where:

• the original pay category is Coupon/Credit

• the pay type is the alternate pay type (such as a refund check)

• the pay type on the order is the original pay type for the refund

The system will post the offset to sales based on the original pay type on the order. Continuing the example, the system would post the offset to sales to the G/L # defined for the merchandise credit pay type.

No posting is made to the General Ledger when the type of refund is changed (due to an alternate refund type or if the operator changes it). However, when refunds are processed, the system will make the appropriate posting to the General Ledger.

For more information: See Working with Pay Types (WPAY) and How Pay Type Determines Refund Type.

Billing Returns

These transactions post during BILL_Async for all pay categories (cash/check, credit card, A/R, C.O.D., and coupon/ credit) when a credit invoice is created for an item return, overpayment, item, or order cancellation. This establishes the liability for the refund.

	Debit	Credit
G/L Account:	Merchandise Returns G/L # (or Merchandise Sales G/L # from the Division table if no returns G/L # is defined)	Returns G/L # ("Offset")
Table:	Item Class table or Division table	Pay Type G/L table

Refunding Overpayments by Cash/Check

No entry is posted to the General Ledger when there is an overpayment on a prepaid order. It is assumed that the deferred liability created for the cash received establishes the total liability, including the refund liability.

Note: In all cases for overpayment, the system will debit the sales G/L # in the Pay Type G/L table for the original pay type and credit the refund G/L # in the Pay Type G/L table for the current pay type.

When the refund is issued, a posting is made to the General Ledger, based on the refund reason and the pay category. The refund reason in this case is Overpayment (O) and the pay category is Cash/Check. This transaction is posted in Processing Refunds (MREF):

	Debit	Credit
G/L Account:	Sales G/L# (for refund’s original pay type)	Refund G/L # (for refund’s current pay type)
Table:	Pay Type G/L table	Pay Type G/L table

The refund G/L # from the Pay Type G/L table (for the prepaid pay type) may be the same G/L # as the cash G/L # in the Default Bank for Cash Posting from Order Entry (D17) system control value.

Refunding Overpayments for Coupons & Merchandise Credits

If an order is paid with a credit form of payment (such as any pay type with a pay category of Coupon/Credit and a refund is generated for the overpayment (refund reason = O), this transaction posts to the General Ledger when the refund is issued:

	Debit	Credit
G/L Account:	Sales G/L # (for refund’s original pay type)	Refund G/L # (for refund’s current pay type)
Table:	Pay Type G/L table	Pay Type G/L table

Refunds in Original Pay Type for Returns

When you process refunds, these transactions are posted to the General Ledger if the original refund pay type and current refund pay type are the same:

Pay Category	Type	G/L Account	Table
Cash/Check or Coupon/Credit:	Debit	Returns G/L#	Pay Type G/L table
	Credit	Refund G/L #	Pay Type G/L table

Note: If the original pay type and the current pay type are the same, no postings are made for credit cards and A/R credits when refunds are processed. C.O.D. credits must have an alternate refund type so that the original and current pay type will never be the same.

Refunds in Alternate Pay Type

These transactions are posted to the General Ledger if the pay type for a refund is different from the original pay type on the order:

Pay Category	Type	G/L Account	Table
Cash/Check:	Debit	Returns G/L # for the original refund pay type. If no returns G/L is defined, post transaction to sales.	Pay Type G/L table
	Credit	Refund G/L # for the current pay type	Pay Type G/L table
Coupon/ Credit, Credit card, A/R, and COD:	Debit	Returns G/L # for the original refund pay type	Pay Type G/L table
	Credit	Refund G/L # for the current pay type	Pay Type G/L table

Stored value card refunds in place of merchandise credits: If the Generate SVC Refund for all Merchandise Credit Refunds (I72) system control value is selected, the system generates a stored value card refund in place of a merchandise credit refund for a coupon pay type. In this situation, the system posts both the debit and credit transactions to the general ledger against the coupon/credit pay type on the order:

	Debit	Credit
G/L Account:	Returns G/L # for the coupon pay type	Pay Type G/L table
Table:	Refund G/L # for the coupon pay type	Pay Type G/L table

However, if you change a merchandise credit refund for a coupon pay type to a stored value card refund (by entering a stored value card pay type in the Pay type field at the Change Refund Screen), the system posts the debit transaction to the original coupon pay type and the credit transaction to the stored value card pay type:

	Debit	Credit
G/L Account:	Returns G/L # for the coupon pay type	Pay Type G/L table
Table:	Refund G/L # for the stored value card pay type	Pay Type G/L table

Because the general ledger postings for stored value card refunds varies based on how the stored value card refund was generated, you may wish to define the same Refund general ledger number for both your coupon pay type and stored value card pay type.

Writing Off Refunds

The system writes off refunds automatically when they are less than the minimum refund amount from the Pay Type table. Also, you can write off a refund manually at the Work with Refunds Screen. When you run Processing Refunds (MREF), all refunds with a write-off status (W) will be written off. These postings are made to the General Ledger for writeoffs:

Overpayments:
	Debit	Credit
G/L Account:	Sales G/L # ("Offset")	Write-off G/L #
Table:	Pay Type G/L table for the pay type on the Refund table (original pay type for the refund)	Pay Type G/L table for the pay type in the Refund table (original pay type for the refund).

Returns:
	Debit	Credit
G/L Account:	Returns G/L#	Write-off G/L #
Table:	Pay Type G/L table for the pay type on the Refund table (original pay type for the refund)	Pay Type G/L table for the pay type in the Refund table (original pay type for the refund)

Canceling Refunds

You would typically cancel refunds if the refunds are created incorrectly and you want to stop them from being issued.

These postings are made to the General Ledger for a canceled refund when you process refunds:

Overpayments:
	Debit	Credit
G/L Account:	Sales G/L # ("Offset")	Cancel G/L #
Table:	Pay Type G/L table for the pay type on the Refund table (original pay type for the refund)	Pay Type G/L table for the pay type in the Refund table (original pay type for the refund).

Returns:
	Debit	Credit
G/L Account:	Returns G/L#	Cancel G/L #
Table:	Pay Type G/L table for the pay type on the Refund table (original pay type for the refund)	Pay Type G/L table for the pay type on the Refund table (original pay type for the refund)

Voiding/Reinstating Refund Checks

You can void and reinstate a refund check manually at the Work with Check Reconciliation Screen. These postings are made to the General Ledger for voiding and reinstating refund checks:

	Debit	Credit
G/L Account:	Refund G/L #	Sales G/L #
Table:	Pay Type G/L table for the pay type associated with the refund check	Pay Type G/L table for the pay type associated with the refund check

Note: If you do not have the general ledger numbers set up in the Pay Type G/L table at the time the system initially posts the refund to the general ledger, but then populate the general ledger numbers in the Pay Type G/L table, the system will post to a 0 general ledger account when you void and reinstate a check.

---

1. The system uses the Sales G/L # if the Sale/Deferred G/L # for the pay type is blank
2. The system uses the Sales G/L # if the Sale/Installment G/L # for the pay type is blank