Understanding order transactions in batches and reports

Training course

iMIS Desktop offered two order entry options:

  • Simple Order Entry
  • Full Order Entry

With iMIS EMS, there is no Simple Order Entry, and all users have Full Order Entry, which may cause order transactions to appear differently than they did in iMIS Desktop. With Full Order Entry, the presumption is that you are taking the order through the different stages of the order process, such as converting it from a quote to an actual order, printing shipping papers for shipping, and then ultimately generating an invoice for the order.

Since the order goes through these stages, at the time the order is placed and paid, the payment is applied to a prepaid invoice, because the order is not initially invoiced. Once the order is invoiced, iMIS transfers the credit for this prepayment against the order invoice (this invoice is created at the time orders are invoiced).

The transactions created when paying for the order at the same time it is placed works the same way as Full Order Entry transactions, so even though the settings for orders say to go ahead and move them to invoice stage at the time of the order is placed, iMIS still creates these three transaction lines.

Defining the default GL accounts used for orders

It is important to mention that certain default GL accounts must be configured when working with orders, whether you are using inventory or not. To define these accounts, do the following:

  1. Go to Settings > Finance > Financial entities.
  2. Open the default financial entity.
  3. Click the Default accounts tab.

    4. The default accounts, with a callout around the Prepaid and Transfer/Clearing accounts.

  4. Make sure the following accounts have the appropriate GL accounts defined:

      Even if you are working with inventory or non-inventory orders, the Prepaid account is used.

      Each order is comprised of three transaction lines, and the first transaction is always deposited to the Prepaid account. The Prepaid account is where the money is initially held until the order is invoiced. For non-inventory orders, the order is invoiced immediately, so the batch details all three transaction rows right away (see example 1 below).

      For orders with inventory items, the Prepaid account is used to hold the payment until the order is invoiced. With inventory orders, there is a delay between the time that the payment is received and the time the product is actually shipped to the customer. This results in a liability – during that interval in time - in that money has been received in advance of the customer receiving the goods or services, or a delay between the payment and the fulfillment of the order.

      In order to properly track this prepayment stage – between the time the payment is received and the time it is applied to the completed order’s invoice – the prepayment amount is properly reported as a liability. The type of liability is commonly referred to as Unearned Income, or a type of Deferred Revenue.After the product is shipped and invoiced (or the order is fulfilled), then the Prepaid account amount is reversed and the prepayment is applied to the invoice.

      The Transfer/Clearing account is needed when a transaction must be recorded in two parts. It is sometimes referred to as a Wash Account, because the goal is that it will never have a balance. The reason that it is needed in the order entry prepayment and invoicing scenarios is that the prepayment amount is actually tracked in a special purpose prepayment invoice until the order is invoiced and the prepayment amount is applied to the invoice (see Example 2 below).

      A pair of transfer transactions, using the transfer/clearing account, is required in order to move that balance from one invoice to another invoice. This is because the actual accounting (debit to the Prepaid account and credit to Income) is split between two transactions:

      • The Prepaid account entry represented in the transaction to close out the Prepaid Invoice balance
      • The credit to Income represented in the transaction to invoice the order, the transfer/clearing account is supplying the in-and-out balancing credit and debit entries.

      Note that, for an inventory order, it may be a day or two or even weeks, in some cases, before the order is completely fulfilled and the liability is fully reversed.

  5. Click Save.

Example 1: Non-inventory item purchased

When there is no inventory and the settings are in place to automatically invoice and set to complete (Settings > Commerce > General), all orders for non-inventory products are invoiced immediately and the payment is applied.

Commerce settings with a callout around Default order type and Order stage if order does not contain inventory items

In this example, someone ordered a non-inventory item and paid for the item at the time of purchase.

Transaction 8241 is the prepayment for the order and is the first transaction created. This is a separate transaction that is created up front for the payment, and then applies the payment when the order is subsequently invoiced.

An example of a non-inventory transaction with a prepayment applied

Transactions 8242 and 8243 apply the application of the prepayment to the actual order invoice. In the end, the PP and TR lines net out and you are only left with the DIST (Income) and PAY (Cash Account) lines that are exported to your GL package. Since the PP and TR lines net to zero, they are not included in the GL export.

The prepayment nets out with the created invoice

Example 2: Inventory item purchased

When inventory is involved, there is a delay between the time that the payment is received and the time the product is actually shipped to the customer. This results in a liability – during that interval in time - in that money has been received in advance of the customer receiving the goods or services.

In order to properly track this prepayment stage – between the time the payment is received and the time it is applied to the completed order’s invoice – the prepayment amount is properly reported as a liability. The type of liability is commonly referred to as Unearned Income, or a type of Deferred Revenue. This is the batch view right after the inventory item is purchased but has not yet been invoiced:

An example of a prepayment for an inventory item

Once the product is shipped and invoiced (or the order is fulfilled), then the Unearned Income is reversed and the prepayment is applied to the invoice.

Note: The Batch date reflects the Invoice date that was entered in the Generate invoices window, and the Created By field always displays AUTOBATCHINVOICE.

Showing the transactions created after the product has shipped and invoiced

This completes the entries to the batch for the initial prepayment recording (that was created earlier when the order was entered and paid in full), followed by the remaining transactions that were generated when the order was invoiced.

The entries that were made to the Prepaid account are labeled with the abbreviation of PP. The wash entries to the Transfer/Clearing account are labeled with the abbreviation of TR. You can see that the PP entries ultimately wash out, although this process may sometimes take days or weeks for an inventory scenario. The TR entries should always immediately offset each other. There should never be a balance.

The entries interact with the invoice in the following ways:

  • 8248 – Records the payment and the prepaid account liability and generates the special purpose PP invoice through which the liability credit balance is tracked.
  • 8249 – Reverses the prepaid account liability related to this now fully fulfilled and invoiced order and reverses/transfers the credit balance to pay off the newly created order’s invoice balance (or applies the credit).
  • 8250 – Records the credit to income and completes the transfer of the open credit balance from the PP invoice through the TR entry.

The batch transaction detail