Chapter 40: General Ledger Overview
Purpose: The General Ledger Overview describes how the system captures General Ledger transactions automatically in an interface file 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 file 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 chapter:
• Posting Changes to Inventory Value
• Selecting the Division for Inventory Transactions
• Amount of Posting for Inventory
• * = Change Average or Standard Cost
• User-defined Inventory Transaction Codes
• Posting Merchandise Sales and Discounts for Price Overrides
• Deferred Liability for Prepaid Orders
• Deferred Liability for Prepaid Memberships
• Credit Liability for Coupons
• Deposits
• Posting Delivery Confirmation
• Delivery Confirmation for Standard Shipment and Billing Process
• Delivery Confirmation for Return Process
• Delivery Confirmation for Discount Process
• Delivery Confirmation for Express Bill Process
• How Pay Types Control Refunds
• Refunding Overpayments by Cash/Check
• Refunding Overpayments for Coupons & Merchandise Credits
• Refunds in Original Pay Type for Returns
• Refunds in Alternate Pay Type
• Voiding/Reinstating Refund Checks
Posting Changes to Inventory Value
Purpose: Changes to inventory resulting from inventory transactions post automatically to the General Ledger Interface file 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.
Most general ledger numbers are defined in the Division file. See Chapter 3: 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 system control value to Y, the system uses the division associated with the source code, if any, at the order detail line level.
Enter a valid General Ledger account number in the Inv G/L # (Inventory general ledger account number) field in the Item file 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 file.
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.
Enter a valid General Ledger account number in the Inventory value G/L #field in the Warehouse file 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 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."
Use Working with Item Classes (WICL) to define general ledger account numbers that override the account numbers you define for a 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 Costing Method (A25) defined in the System Control file:
• 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 file or the extended FIFO cost from the FIFO layers to the General Ledger, depending on the costing method defined in the System Control file.
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 enter Y in 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. |
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. |
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 file |
Credit G/L account in Item or Warehouse file |
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 (-).
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 file |
|
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 set to Y:
Effect on Inventory is Positive (+) |
Effect on Inventory is Negative (-) |
Debit the G/L account in Item or Warehouse file |
|
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.
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 file for the transfer "to" item (using "to" item cost) |
|
Credit G/L account defined in Item or Warehouse file for the transfer "from" item (using "from" item cost) |
|
Debit the Item to Item Transfer G/L account from the Division file 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.
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 file |
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 set to Y:
|
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.
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 file |
Credit G/L account in Item or Warehouse file |
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.
The system uses this code to adjust on-hand counts for an item after a physical inventory file 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 file |
Credit G/L account in Item or Warehouse file |
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 (-).
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 file |
|
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 set to Y, 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 Work with Purchase Order Additional Charges.
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 |
|
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 file for the transfer "to" warehouse |
Credit G/L account in Item or Warehouse file for the transfer "to" warehouse |
Credit G/L account defined in Item or Warehouse file for the transfer "from" warehouse |
Debit G/L account defined in the Item or Warehouse file 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 (-).
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 set to 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 file |
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.
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 file 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 file |
Credit G/L account defined in the Item or Warehouse file |
Credit G/L account defined for the inventory transaction code |
Debit G/L account defined for the inventory transaction code |
* = Change Average or Standard Cost
The system uses this code to increase or decrease total inventory valuation to reflect a change in an item/SKU’s 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/SKU’s 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/SKU’s (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 file |
Credit G/L account defined in the Item or Warehouse file |
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 file 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 file |
Credit G/L account in Item or Warehouse file |
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 (-).
Hierarchy: The system uses this hierarchy when posting sales and returns to the General Ledger:
1. Item Class File
2. Division File
Sales posting |
||
|
Debit |
Credit |
G/L Account: |
Sales G/L # |
Sales G/L # |
File: |
Pay Type G/L file |
Item Class file or Division file |
Sales posting for a deferred payment plan |
||
|
Debit |
Credit |
G/L Account: |
Sale/Deferred G/L #*1 |
Sales G/L # |
File: |
Pay Type G/L file |
Item Class file or Division file |
Sales posting for an installment payment plan |
||
|
Debit |
Credit |
G/L Account: |
Sale/Installment G/L #2 |
Sales G/L # |
File: |
Pay Type G/L file |
Item Class or Division file |
Returns posting for a deferred payment plan |
||
|
Debit |
Credit |
G/L Account: |
Returns G/L # |
Return/Deferred G/L #** |
File: |
Item Class file or Division file |
Pay Type G/L file |
Returns posting for an installment payment plan |
||
|
Debit |
Credit |
G/L Account: |
Returns G/L # |
Return/Installment G/L #*** |
File: |
Item Class file or Division file |
Pay Type G/L file |
*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 system control value is set to Y. See that system control value for more information.
Pre-billing: See Pre-Billed Item Processing and Updates for a discussion on general ledger updates that occur when you pre-bill an item.
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) |
File: |
Pay Type G/L file |
Item Class or Division file |
Item Class or Division file |
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.
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 e-commerce interface. If there is a price override reason code in the new order message, the system always processes these orders as if the field is set to N.
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 # |
File: |
Bank file (use the default bank, as defined in the Default Bank for Cash Posting from Order Entry (D17) field in the System Control file; SCV #D17) |
Pay Type G/L file |
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 # |
File: |
Bank file (use the default bank, as defined in the Default Bank for Cash Posting from Order Entry (D17) field in the System Control file; SCV #D17) |
Division G/L file |
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 # |
File: |
Division G/L file |
Pay Type G/L file |
Important: These postings occur only if the Deferred Liability Cash Post Method (C48) system control value is set to ORDER (Order Entry).
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 # |
File: |
Pay Type G/L file |
Pay Type G/L file |
This posting occurs only if the Post Coupon Liability to G/L for New Orders (D52) system control value is set to Y.
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 #* |
File: |
Bank for A/R Credit Card Deposits system control value |
Pay Type file |
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 |
File: |
Pay Type file |
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.
The system posts the following to the general ledger when you apply a payment towards a debit open item at the Pay Open Items Screen or Work with Payment Details Screen.
Apply Payment towards an A/R Open Item |
||
|
Debit |
Credit |
G/L Account: |
A/R Cash G/L |
A/R G/L |
File: |
Bank The system does not use the general ledger number you enter at the Work with Payment Details Screen. |
Division |
The system posts the following to the general ledger when you post a discount amount to an A/R open item at the Work with Payment Details Screen.
Post Discount towards an A/R Open Item |
||
|
Debit |
Credit |
G/L Account: |
Sundry Cash Receipts Debit G/L |
A/R G/L |
File: |
The general ledger number you enter at the Work with Payment Details Screen. |
Division |
The system posts the following to the general ledger when you perform a write-off adjustment at the Work with Payment Details Screen.
Post Write-off to A/R Open Item |
||
|
Debit |
Credit |
G/L Account: |
Sundry Cash Receipts Debit G/L |
A/R G/L |
File: |
Manually entered on the Work with Payment Details Screen |
Division |
The system posts the following to the general ledger when you use the Automatic A/R Open Item Write-off Process.
Automatic A/R Write-off |
||
|
Debit |
Credit |
G/L Account: |
Sundry Cash Receipts Debit G/L |
A/R G/L |
File: |
Defined in the G/L Account to Offset Automatic A/R Write-offs (K61) system control value |
Division defined in the Default Division (K62) system control value |
Purpose: When the system creates an order line history record for order line activity code V (Delivered), if a Delivery Confirmation general ledger number has been defined for the division associated with the order in the Working with Divisions (WDIV) menu option, the system posts the Delivery Confirmation to the General Ledger.
When is a Delivery Confirmation created? The system creates an order line history record for order line activity code V (Delivered) when:
• you flag a quantity of the item on the order line as Delivered through the Order Line History In Message (CWORDLNHSTIN) or Manual Delivery Confirmation (MIDC) menu option.
• you create a return or exchange for the item on the order line if a Delivery Confirmation general ledger number has been defined for the division associated with the order.
• you apply a discount to the shipped quantity of the item on an order line on the Discount Price Window (Applying a Discount to an Item) if a Delivery Confirmation general ledger number has been defined for the division associated with the order.
• you express bill an item on an order line if a Delivery Confirmation general ledger number has been defined for the division associated with the order.
Which division? The setting of the Post Sales G/L Using Division at Order Line Source Code (F17) system control value determines the division associated with the order.
• If set to Y, the system posts the Delivery Confirmation to the division associated with the source code on the order line. If a source code has not been defined for the order line, the system posts the Delivery Confirmation to the division associated with the source code on the order header.
• If set to N, the system posts the Delivery Confirmation to the division associated with the source code on the order header.
Note: If a Delivery Confirmation general ledger number has not been defined for the division, the system does not post the delivery confirmation to the general ledger.
Transaction amount: The transaction amount for the delivery confirmation general ledger is for the merchandise amount only. The system uses the following calculation to determine the delivery confirmation transaction amount:
OLH quantity in the Order Line History file X ODT price in the Order Detail file = delivery confirmation transaction amount
Transaction date: The transaction date represents the date the system posted the delivery confirmation to the general ledger. If the delivery confirmation was created through the Order Line History In Message (CWORDLNHSTIN), the transaction date for the delivery confirmation general ledger represents the date the Order Line History (ORDLNHSTIN) job in the Working with Integration Layer Processes (IJCT) menu option processed the Order Line History In Message (CWORDLNHSTIN) with an activity_code of V (Delivered); the transaction date does not represent the contact_date or ext_sys_date defined in the message or the date the ORDLNHSTIN job was started.
Sending delivery confirmations for set items: When you send a delivery confirmation for a set item, make sure to send the delivery confirmation for the item at the level where you price the set:
• If you price sets at the set master level, send a delivery confirmation for the set master item.
• If you price sets at the set component level, send a delivery confirmation for each component item.
This will ensure that the Delivery Confirmation posting to the general ledger is correct.
You can also send a delivery confirmation for both the set master item and each component item.
General ledger postings: The system uses this hierarchy when posting delivery confirmation to the General Ledger:
1. Item Class File
2. Division File
Delivery Confirmation posting |
||
|
Debit |
Credit |
G/L Account: |
Merchandise Sales # |
Delivery Confirmation # |
File: |
Item Class or Division file |
Division file |
Delivery Confirmation for Standard Shipment and Billing Process
When a shipment confirmation is received and the order is processed through Billing, the system posts sales to the general ledger: debits the Sales general ledger number at the pay type level and credits the Merchandise Sales general ledger number at the item class level or division level. See Posting Sales for more information on how the system posts sales to the general ledger.
If you are posting delivery confirmations to the general ledger, the sales posting represents where the revenue is kept until a delivery confirmation is received. The Merchandise Sales general ledger number at the item class or division level represents the temporary general ledger account.
When the delivery confirmation is received, the system posts the delivery confirmation to the general ledger: debits the Merchandise sales general ledger number at the item class level or division level and credits the Delivery confirmation general ledger number at the division level.
The Delivery confirmation general ledger account is the account that recognizes the revenue once the merchandise has been received by the customer.
Sales posting |
||
|
Debit |
Credit |
G/L Account: |
Sales # |
Merchandise Sales # |
File: |
Pay Type file |
Item Class or Division file |
Delivery Confirmation posting |
||
G/L Account: |
Merchandise Sales # |
Delivery Confirmation # |
File: |
Item Class or Division file |
Division file |
Example -- Delivery Confirmation for Standard Shipment and Billing: The following general ledger accounts are defined:
File |
General Ledger Account |
General Ledger # |
Pay Type file |
Sales |
188888 |
Division file |
Merchandise Sales |
200623 |
Delivery Confirmation |
200626 |
CWDirect receives a shipment confirmation and bills an order, posting the sales to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
188888 |
10/17 |
20.00 |
Sale/Credit Card |
206 |
06 |
200623 |
10/17 |
20.00CR |
Sale/Merchandise Sale |
CWDirect receives a delivery confirmation and posts the delivery confirmation to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
200623 |
10/18 |
20.00 |
Delivery Confirmation Offset |
206 |
06 |
200626 |
10/18 |
20.00CR |
Delivery Confirmation |
Delivery Confirmation for Return Process
When a credit invoice is created during Billing, the system posts the return to the general ledger: debits the Merchandise Returns general ledger number at the item class level or division level and credits the Returns general ledger number at the pay type level.
If a Merchandise Returns general ledger number has not been defined at the item class level or division level, then the system debits the Merchandise Sales general ledger number at the item class level or division level and credits the Returns general ledger number at the pay type level.
In addition, if a delivery confirmation does not exist for the quantity returned, the system posts the delivery confirmation to the general ledger during returns processing: debits the Merchandise Sales general ledger at the item class level or division level and credits the Delivery confirmation general ledger number at the division level.
Note: If a quantity of the returned item is already associated with a delivery confirmation, the system posts the delivery confirmation to the general ledger for the quantity of the returned item that is not already associated with a delivery confirmation general ledger posting.
See Posting Refunds for more information on how the system posts returns to the general ledger.
Sales posting |
||
|
Debit |
Credit |
G/L Account: |
Sales # |
Merchandise Sales # |
File: |
Pay Type file |
Item Class or Division file |
Returns posting |
||
G/L Account: |
Merchandise Returns # (or Merchandise Sales #) |
Returns # |
File: |
Item Class or Division file |
Pay Type G/L file |
Delivery Confirmation posting |
||
G/L Account: |
Merchandise Sales # |
Delivery Confirmation # |
File: |
Item Class or Division file |
Division file |
Example -- Delivery Confirmation for Return Process: The following general ledger accounts are defined:
File |
General Ledger Account |
General Ledger # |
Pay Type file |
Sales |
188888 |
Returns |
177777 |
|
Division file |
Merchandise Sales |
200623 |
Delivery Confirmation |
200626 |
|
Merchandise Returns |
200622 |
CWDirect receives a shipment confirmation and bills an order, posting the sales to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
188888 |
10/17 |
20.00 |
Sale/Credit Card |
206 |
06 |
200623 |
10/17 |
20.00CR |
Sale/Merchandise Sale |
The customer returns the merchandise; CWDirect posts the return to the general ledger. In addition, because the merchandise is not associated with a delivery confirmation, CWDirect also posts the delivery confirmation to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
200622 |
10/18 |
20.00 |
Sale/Merchandise Return |
206 |
06 |
177777 |
10/18 |
20.00CR |
Sale/Credit Card |
206 |
06 |
200623 |
10/18 |
20.00 |
Delivery Confirmation Offset |
206 |
06 |
200626 |
10/18 |
20.00CR |
Delivery Confirmation |
Delivery Confirmation for Discount Process
When a discount is applied to the shipped quantity of an item on an order line, the system posts the discount to the general ledger: debits the Merchandise Returns general ledger number at the item class level or division level and credits the Returns general ledger number at the pay type level.
If a Merchandise Returns general ledger number has not been defined at the item class level or division level, then the system debits the Merchandise Sales general ledger number at the item class level or division level and credits the Returns general ledger number at the pay type level.
In addition, if a delivery confirmation does not exist for the quantity discounted, the system posts the delivery confirmation to the general ledger during discount processing: debits the Merchandise Sales general ledger at the item class level or division level and credits the Delivery confirmation general ledger number at the division level.
Note: If a quantity of the discounted item is already associated with a delivery confirmation, the system posts the delivery confirmation to the general ledger for the quantity of the discounted item that is not already associated with a delivery confirmation general ledger posting.
See Posting Merchandise Sales and Discounts for Price Overrides for more information on how the system posts discounts to the general ledger.
Sales posting |
||
|
Debit |
Credit |
G/L Account: |
Sales # |
Merchandise Sales # |
File: |
Pay Type file |
Item Class or Division file |
Discount posting |
||
G/L Account: |
Merchandise Returns # (or Merchandise Sales #) |
Returns # |
File: |
Item Class or Division file |
Pay Type G/L file |
Delivery Confirmation posting |
||
G/L Account: |
Merchandise Sales # |
Delivery Confirmation # |
File: |
Item Class or Division file |
Division file |
Example -- Delivery Confirmation for Return Process: The following general ledger accounts are defined:
File |
General Ledger Account |
General Ledger # |
Pay Type file |
Sales |
188888 |
Returns |
177777 |
|
Division file |
Merchandise Sales |
200623 |
Delivery Confirmation |
200626 |
|
Merchandise Returns |
200622 |
CWDirect receives a shipment confirmation and bills an order, posting the sales to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
188888 |
10/17 |
20.00 |
Sale/Credit Card |
206 |
06 |
200623 |
10/17 |
20.00CR |
Sale/Merchandise Sale |
The customer returns the merchandise; CWDirect posts the return to the general ledger. In addition, because the merchandise is not associated with a delivery confirmation, CWDirect also posts the delivery confirmation to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
200622 |
10/18 |
4.00 |
Sale/Merchandise Return |
206 |
06 |
177777 |
10/18 |
4.00CR |
Sale/Credit Card |
206 |
06 |
200623 |
10/18 |
20.00 |
Delivery Confirmation Offset |
206 |
06 |
200626 |
10/18 |
20.00CR |
Delivery Confirmation |
Delivery Confirmation for Express Bill Process
When you express bill an item on an order line, the system posts the express bill to the general ledger: debits the Sales general ledger number at the pay type level and credits the Merchandise Sales general ledger number at the item class level or division level.
In addition, if a delivery confirmation does not exist for the quantity express billed, the system posts the delivery confirmation to the general ledger during express bill processing: debits the Merchandise Sales general ledger at the item class level or division level and credits the Delivery confirmation general ledger number at the division level.
Express Bill posting |
||
|
Debit |
Credit |
G/L Account: |
Sales # |
Merchandise Sales # |
File: |
Pay Type file |
Item Class or Division file |
Delivery Confirmation posting |
||
G/L Account: |
Merchandise Sales # |
Delivery Confirmation # |
File: |
Item Class or Division file |
Division file |
Example -- Delivery Confirmation for Express Bill: The following general ledger accounts are defined:
File |
General Ledger Account |
General Ledger # |
Pay Type file |
Sales |
188888 |
Division file |
Merchandise Sales |
200623 |
Delivery Confirmation |
200626 |
CWDirect express bills an order, posting the sales to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
188888 |
10/17 |
20.00 |
Sale/Credit Card |
206 |
06 |
200623 |
10/17 |
20.00CR |
Sale/Merchandise Sale |
CWDirect immediately posts the delivery confirmation to the general ledger.
Ent |
Div |
G/L # |
Date |
Amount |
Journal Source |
206 |
06 |
200623 |
10/18 |
20.00 |
Delivery Confirmation Offset |
206 |
06 |
200626 |
10/18 |
20.00CR |
Delivery Confirmation |
Purpose: The General Ledger Interface file 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.
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 5 (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 Chapter 5: Working with Pay Types (WPAY) and How Pay Type Determines Refund Type.
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 file if no returns G/L # is defined) |
Returns G/L # ("Offset") |
File: |
Item Class file or Division file |
Pay Type G/L file |
Refunding a pre-billed deposit: See Cancellations, Soldouts, and Returns for a discussion on general ledger updates that occur when you refund the pre-billed deposit for an item.
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 file for the original pay type and credit the refund G/L # in the Pay Type G/L file 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 O (Overpayment) and the pay category is 1 (Cash/Checks). 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) |
File: |
Pay Type G/L file |
Pay Type G/L file |
The refund G/L # defined in the Pay Type G/L file (for the prepaid pay type) may be the same G/L # as the cash G/L # defined 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 5 = 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) |
File: |
Pay Type G/L file |
Pay Type G/L file |
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 |
File |
Cash/Check or Coupon/Credit: |
Debit |
Returns G/L# |
Pay Type G/L file |
|
Credit |
Refund G/L # |
Pay Type G/L file |
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.
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 |
File |
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 file |
|
Credit |
Refund G/L # for the current pay type |
Pay Type G/L file |
Coupon/ Credit, Credit card, A/R, and COD: |
Debit |
Returns G/L # for the original refund pay type |
Pay Type G/L file |
|
Credit |
Refund G/L # for the current pay type |
Pay Type G/L file |
Stored value card refunds in place of merchandise credits: If the Generate SVC Refund for all Merchandise Credit Refunds (I72) system control value is set to Y, 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 file |
File: |
Refund G/L # for the coupon pay type |
Pay Type G/L file |
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 file |
File: |
Refund G/L # for the stored value card pay type |
Pay Type G/L file |
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.
The system writes off refunds automatically when they are less than the minimum refund amount defined in the Pay Type file. 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 # |
File: |
Pay Type G/L file for the pay type on the Refund file (original pay type for the refund) |
Pay Type G/L file for the pay type in the Refund file (original pay type for the refund). |
Returns: |
||
|
Debit |
Credit |
G/L Account: |
Returns G/L# |
Write-off G/L # |
File: |
Pay Type G/L file for the pay type on the Refund file (original pay type for the refund) |
Pay Type G/L file for the pay type in the Refund file (original pay type for the refund) |
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 # |
File: |
Pay Type G/L file for the pay type on the Refund file (original pay type for the refund) |
Pay Type G/L file for the pay type in the Refund file (original pay type for the refund). |
Returns: |
||
|
Debit |
Credit |
G/L Account: |
Returns G/L# |
Cancel G/L # |
File: |
Pay Type G/L file for the pay type on the Refund file (original pay type for the refund) |
Pay Type G/L file for the pay type on the Refund file (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 # |
File: |
Pay Type G/L file for the pay type associated with the refund check |
Pay Type G/L file 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 file 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 file, the system will post to a 0 general ledger account when you void and reinstate a check.
- The system uses the Sales G/L # if the Sale/Deferred G/L # for the pay type is blank
- The system uses the Sales G/L # if the Sale/Installment G/L # for the pay type is blank
| Part J: Appendices | Contents | SCVs | Search | Glossary | Reports | XML | Index | Chapter 41: Displaying the General Ledger Interface (DGLI) |
AP_APPA CWDirect 18.0 August 2015 OTN