Oracle Applications: what is a transaction? What are Transaction Types?

First, what is a transaction? Oracle uses transaction as a catch-all term for invoices, credit memos, debit memos and commitments (activities you perform with the customer). Receipts may even be considered a transaction in some instances but I will exclude them from this discussion.

A Transaction Type is a name you give to a transaction. It:

- Provides the rule for how activities are processed, for instance, will there be tax and/or freight?
- Determines if this activity will be posted to the General Ledger
- Identifies the type of transaction: invoice, credit memo, debit memo, chargeback, deposit or guarantee
- Defines if this item will create an open receivable (appear on the aging)
- Provides the default accounts to use when processing this transaction
- Tells, if this is an invoice, the name of the related credit memo type.

The Transaction Type is also used to select what you wish to view on many of the standard reports and is usually displayed with each transaction on the reports and screens.

As you can see, it is a very powerful tool! And, with the proper planning, you can take advantage of it – without customizations!

By asking the following questions, you easily come up with a plan for defining what your Transaction Types will be and how you will use them.

1) List each Accounts Receivable account you wish to use. There should be at least one Transaction Type per account.

2) Do you have any transactions that exclude tax? Exclude freight? If this is not applicable for all of the transactions, make a list of which types will include tax and/or freight and which will not.

3) When reporting, what is the most important factor in grouping the data? Plant? International or Domestic? Type of business? Division?

- What is the next most important?
- And the next?
- And for each, what are the possible values?

4) Will you need to create any transactions that do not create journal entries? Any that do not create open receivables (items to appear on your aging)?

Why would you create a transaction that does not post to the General Ledger or crate an open receivable? Typical scenarios are proforma invoices (for customs): they need to look complete, professional and accurate. But, you really do not want to book the activity to the General Ledger or to create an open item for the Aging. You can set up a special Transaction Type and un-check “Post to GL” and “Create an Open Receivable.”

Some companies with high volumes of credit card activities may check “Post to GL” but leave “Create an Open Receivable” as unchecked. They then use Journal Entries to post the cash and offset the Receivables account. How will this work for you?

5) Will you use Commitments? Deposits (where the customer gives you money up front and you just use it until you run out). Or, Guarantees (where the customer commits to buy a certain dollar amount and you track their sales to ensure that they do actually spend as much as they said they would).

Either of these options must be set up as specific Transaction Types with special Class values.

6) Will you use deferred revenue recognition (Unearned Account)? Deferred Receivables recognition (Unbilled Account)? If Yes to either, what will the Unearned Revenue and Unbilled Receivables accounts be and what Accounts Receivable account is associated with each?

7) Will you ever create debit memos? These may be for special activities such as creating Refund Checks, non-project related or non-order related sales (for example, scrap sales). If Yes, set up another Transaction Type.

Another consideration is how you name the Transaction Types. On most of the standard reports you can only see the first four characters of the name. If you call one Transaction Type “International Product Sales” and another “International Service” they will both appear as “Inte” on standard reports and you will have lost the distinction. With this in mind, I like to build “intelligence” into the name of the Transaction Types by assigning values to the 4 characters you can see. I assign a separate value to each character or assign a value to the first three characters and use the last character for the type of transaction.

This example is for a company where plant is the most important consideration, followed by international or domestic sale, followed by government or commercial customer and then by the type of activity. We set up the transaction types as follows:

1st Character: P = Phoenix, W = Weston, K = Kings Beach
2nd Character: I = International, D = Domestic
3rd Character: C = Commercial, G = Government
4th Character: I = Invoice, D = Debit Memo, C = Credit Memo

e.g., PIGI is a Phoenix, International, Government Invoice

WICI is a Weston, International, Commercial Invoice

Another example is where the first three characters represent the country that is legally responsible for the sale, while the last character indicates the type of transaction:

e.g., UKII = UK Invoice
FRAC = France Credit Memo
ITLD = Italy Debit Memo

Note that by using the Transaction Types to select which data to print on the standard reports, you can easily select all activity by the first character (e.g., plant – the first type that starts with P through the last type that starts with a P). However, to see just the international activity – based on the third character, you need to either use a custom report or run the report with multiple subsets of the data. It is still worth “coding” the Transaction Type since you can learn a lot about a transaction – all in the 4 characters.

After answering the questions and considering the naming conventions, you are ready to define your Transaction Types. The values you use should naturally fall out of the above process, but you need to take the next step, evaluating how AutoInvoice will work, since that will also impact how you define your types.

If most of your transactions are created outside of Oracle Receivables and imported using AutoInvoice, it is easy to use lots of different Transaction Types. If you are manually creating your transactions, 20 – 30 Transaction Types is probably a good maximum number (otherwise, they may be too overwhelming).

Note that if you are using Oracle Order Entry or Oracle Projects, using the vanilla set up, they both are set up to have very narrow options in terms of the default Transaction Types. One Transaction Type per Order Type and all Projects activity going to the Transaction Type of “PA Invoices.” This is not consistent with all of the work you did above to define the specific Transaction Types. To get past this issue, I usually create a program that runs before AutoInvoice and updates the transactions with the applicable Transaction Types (overriding the defaults from the feeder system). This lets the other applications work the way they work, but still gives you the option to build “intelligence” into the types in Receivables.

Tip: I suggest that you always set up Transaction Types with the options set to never allow over application and to use Natural Application only; otherwise you have transactions that are confusing and difficult to undo.

Following Google Searches Lead To This Post:
order management receivables transaction type
transaction type memo