Banking and Cash Transactions

A transaction in a database system terminates either by a commit (making changes permanent) or a rollback (undoing all changes). Options A and B are incomplete as they only consider one termination mode. Option D is incorrect because transactions do end through these two mechanisms - there are no other ways to complete a transaction.

Credit card management systems typically trigger automatic account cancellation when a delinquency reaches a 90-day aging balance (representing three consecutive missed billing cycles). Younger aging balances (30 or 60 days) trigger collection activities but not automatic cancellation, making other options incorrect.

A transaction ends either when it is committed (changes saved) or rolled back (changes discarded). These are the only two ways a transaction completes. It does not end by only one of these actions.

Oracle Payables supports multiple payment methods including Check, Wire, and Clearing (for electronic payments). DD (Direct Debit) is not a standard payment method in Oracle Payables - it's a banking term but not a Payables payment method type. The system uses Electronic Funds Transfer (EFT) for automated debits, not labeled as 'DD'.

The manual payment method in Oracle Payables is used to record a payment that was made outside the Payables system, such as a handwritten check or a wire payment initiated directly at the bank. You're simply recording the payment transaction for accounting purposes, not creating or printing it. This differs from Quick Payment, which generates the payment within Payables.

Quick Payment in Oracle Payables creates and prints a computer-generated payment to pay a supplier for one or more selected invoices. You select the invoices, and the system generates the payment (check or electronic) immediately. This differs from manual payment (recording external payments) and payment batches (processing multiple suppliers at once).

The payment batch process follows a logical workflow: first modify the payment batch to make any adjustments, then confirm the batch to validate it, format payments to generate the output file, and finally print checks from that formatted output. Option D correctly captures this sequence.

Once a payment batch is formatted, the output file is generated and the batch is essentially frozen for payment purposes. The only valid action from the given options is printing checks from this output file. You cannot change invoice amounts, block suppliers, or prevent specific invoice payments after formatting - those modifications must happen before.

Auto Cash Rule Sets are specifically designed to automatically apply incoming receipts (like those from Lockbox) to open customer invoices. While other transaction types exist, the primary and original purpose of Auto Cash Rules is receipt-to-invoice matching application.

The AR: Enter Transactions form is used to create standard transaction types including Debit Memos (B), Deposits (C), and Invoices (D). However, Chargebacks (A) cannot be created through this form - they are created through the AR: Chargebacks form or generated automatically during receipt application. Chargebacks are a specialized transaction type for disputed invoice portions.

If a receipt's value exceeds the invoice amount and there is no remittance guidance, the entire receipt's status is 'unapplied' or 'partially applied' (with \$1500 applied and \$500 unapplied). According to Oracle Receivables standards, since the receipt has been partially applied to the invoice, the general state of the leftover amount or the receipt status changes, but if the receipt is partially applied, the correct state in the application process is 'unapplied' for the remaining $500. However, standard training questions list 'unapplied' as the stored answer because the unapplied portion is not yet allocated to 'on-account' or a specific refund.

AutoCash rules in Oracle Receivables are applied to QuickCash receipts, which are receipts created through the QuickCash feature for automatic receipt creation and application. Manual receipts are processed differently, and 'automatic' is not a specific receipt type in this context.

The Auto Reconciliation program in Oracle Cash Management automatically matches bank statement lines with transactions, eliminating manual effort. This program compares statement lines against open receipts, payments, and miscellaneous transactions to reconcile them automatically. Sweep Transaction Generation is for cash positioning, Archive Bank Statements for data management, and Cash Forecasting for liquidity planning.

When payments are reconciled in Oracle Cash Management, their status updates to 'reconciled' to indicate they've matched with bank statement lines. This status change prevents duplicate reconciliation and provides audit trail visibility. The workflow ensures payment records reflect their true bank-cleared state for accurate financial reporting.

The bank reconciliation sequence follows logical workflow: first receive the physical/electronic statement from bank, then load and verify it into system (validation step), perform reconciliation to match transactions, and finally post to General Ledger. Loading before verification is impossible, and reconciliation requires loaded data. This sequence ensures data integrity before accounting impact.