Identifies the Currency assigned to the transaction. This is required and comes from the 'Currency' property on the Properties tab of the Customer record view. This field is can not be edited on the transaction.

The Currency identifies the kind of money used for transactions. For example, if a Customer or Vendor is setup with a Currency of "USD" then all transactions for them are stated in terms of US Dollars and all payments received or made must be in US Dollars.

Database Fields: ERPx_MFCurrency.CurrencyID, ERPx_ARTransactionHeader.CurrencySK

Identifies the date of the transaction. This is required and can be edited from the 'Doc Date' field on the Home tab of the Quick Sale record view while in a Status of 'New'.

Database Field: ERPx_ARTransactionHeader.TransactionDate

Identifies the header comment/description of the transaction or batch. This is not required and can be edited from the 'Description' field on the Home tab of the Quick Sale record view.

Database Field: ERPx_ARTransactionHeader.Description

Identifies the Doc No (document number) for the transaction. Unlike a Transaction ID that is system assigned based on the Transaction Class of the Transaction Type, this is a manually entered value. This is not required and can be edited from the 'Description' field on the Home tab of the Quick Sale record view.

Database Field: ERPx_ARTransactionHeader.DocNumber

Identifies the Fiscal Period based on the GL date on the source transaction or manual journal entry. This is required and can be edited from the 'GL Date' field on the Properties tab of the Quick Sale record view while in a Status of 'New'. This value is not stored in the database.

Calculated from: ERPx_ARTransactionHeader.GLDate

Identifies the Fiscal Year based on the GL date on the source transaction or manual journal entry. This is required and can be edited from the 'GL Date' field on the Properties tab of the Quick Sale record view while in a Status of 'New'. This value is not stored in the database. 

Calculated from: ERPx_ARTransactionHeader.GLDate

Identifies the Payment Terms assigned to the transaction.

Database Field: ERPx_MFPaymentTerms.PaymentTermName, ERPx_ARTransactionHeader.PaymentTermsSK

Identifies the Purchase Order number (PO number) entered for the transaction or transaction line item. This is not required and can be edited from the 'PO' field on the Home tab of the record view.

Database Field: ERPx_ARTransactionHeader.PurchaseOrderID

Identifies the ID of the Price List that is assigned to the transaction. This is required and can be edited from the 'Price List' field on the Home tab of the record view while in a Status of 'New'. 

Price Lists are used to store a group of Items with pre-defined prices and effective dates.

Database Field: ERPx_ARTransactionHeader.PriceListHeaderSK

Displays the unique identifier for the Customer record or for the Customer assigned to a transaction. If the Sale was to an Employee, this will be the Employee ID. This is required and can be edited by changing the 'Sold To' field on the Home tab of the record view while in a Status of 'New'. 

Database Field: ARCustomer.CustomerID, ERPx_ARTransactionHeader.CustomerSK

Identifies the name of the Customer record or for the Customer assigned to a transaction. If the Sale was to an Employee, this will be the Employee Name. This is required and can be edited by changing the 'Sold To' field on the Home tab of the record view while in a Status of 'New'. 

Database Field: ERPx_ARCustomer.CustomerName, ERPx_ARTransactionHeader.CustomerSK

Identifies the Status of the transaction. This is required and can be edited from the 'Status' field on the Home tab of the record view while the transaction is in a Status of 'New' or 'Approved'.

Status is used to identify where a transaction, Purchase Order, Price List, BOM, or Master File record is in its life cycle. Records start in a Status of 'New' and progress sequentially through additional statuses until they are 'Posted' or 'Closed'. The list of potential Statuses changes depending on the transaction type.  The Statuses that apply to transactions in this List View include:

New: This is the default Status for all new Transactions. While in the Status of 'New' transactions are considered open and all editable fields are open for edit, no posting or approval validations are performed, GL Dates are not assigned, and journal entries are not created. If the transaction was moved back from Approved to New, the GL Date will be assigned and a Journal Entry will exist.  

Approved: Performs all the data validations required to post the transaction and applies to all Transactions. While in the Status of 'Approved' transactions are considered open but have limited fields open for edit. If one or more validations fail, messages are provided indicating what needs to be corrected. If all the validations pass, then all the fields are disabled except for the Status lookup (and any fields that are always editable), journal entries are created/updated, journal ID's are assigned to the journal entry, and blank 'GL Dates' are assigned.

Ready to Post: Runs the Approval validations and applies to all transactions. While in the Status of 'Ready to Post' transactions are considered closed and all the fields are disabled with the exception of a few fields that are always editable. If one or more validations fail, messages are provided indicating what needs to be corrected. If all the validations pass, then all the fields are disabled with the exception any fields that are always editable and updates the Transaction Status to "Posted".

Posted: Signifies the transaction has been posted and/or applied to a transactions (e.g. Payment Receipt). When a transaction is posted, it updates the General Ledger and/or On Hand Item Balances. While in the Status of 'Posted' transactions are considered closed and all the fields are disabled with the exception of a few fields that are always editable.

Void: Signifies a previously posted transaction has been voided. This status is only available for transactions that support voiding posted records (not all transactions support this). Voided transactions remain in the database and can be viewed from history inquiries.

Deleted: Signifies the transaction has been deleted. When a user deletes an open transaction, in some instances the transaction is not removed from the database but is changed to a Status of 'Deleted'. Deleted transactions are not visible from transaction list views but can be found in inquiries. Transaction in the Status of 'Deleted' are only used a information. 

Replaced: Signifies the transaction was voided or corrected. When a transaction is corrected or Voided, the Status of the original transaction is changed to 'Replaced' and a new transaction is cloned and marked as 'Void'. This is done to ensure that a reversal journal entry can be created and posted in an open fiscal period to record the Void.

Database Fields: ERPx_ARTransactionStatus.StatusName, ERPx_ARTransactionHeader.TransactionStatusSK

Identifies the Tax Class that is assigned to the transaction. This is not required and can be edited by changing the 'Tax Class' field on the Home tab of the record view while in a Status of 'New'. 

Tax Classes store all the Tax Details (individual taxes) used to calculate sales tax on Quick Sales, Fisherman Sales, and Tender Resale transactions. 

Database Field: ERPx_ARTransactionHeader.TaxClassSK

Identifies the unique Transaction ID for each transaction. Clicking on this link opens the Quick Sale record view for the selected record. This is a system assigned number that comes from the 'Transaction Class' and is required, but is never editable by users.

Transaction numbers are system assigned IDs to differentiate unique transactions. Transaction ID's are unique by the unique combination of 'Transaction Type' + 'Transaction Class'. 

Database Field: ERPx_ARTransactionHeader.TransactionID

The unique identifier of the Transaction Class. This is required and is never editable. It is assigned based on the 'Sold To' field on the Home tab of the record view. The Transaction Class defaults from the Transaction Type as follows:

• Customer Sale = Quick Sale - Customer
• Employee = Quick Sale - Employee 
• Fisherman Sale = Default
• Tender Resale = Default

Transaction Classes are used to differentiate transactions within a Transaction Type. For example, Transaction Classes of Fresh and Frozen can be setup for the Transaction Type of 'Sales Order'. Transaction Classes are used in all functional areas throughout the application.

Database Fields: ERPx_ARTransactionClass.TransactionClassDescription, ERPx_ARTransactionHeader.TransactionClassSK

Identifies the Transaction Type for each transaction. This is required and is never editable. It is assigned based on the 'Sold To' field on the Home tab of the record view. The Transaction Class will be displayed as either:

• Customer Sale
• Employee
  

Transaction Types are used to differentiate unique types transactions within the system. Transactions with the same Transaction Type share the same record view pages and business rules. Transaction Types can be further classified using Transaction Classes. Every transaction in the system is assigned a Transaction Type.

Database Fields: ERPx_ARTransactionType.TransactionName, ERPx_ARTransactionClass.TransactionTypeSK,  ERPx_ARTransactionHeader.TransactionClassSK