Oracle 1Z0-1056-26 study materials
Oracle 1Z0-1056-26 study resources

Oracle 1Z0-1056-26: Receivables Configuration and Setup

Oracle 1Z0-1056-26 · Work through your exam, one topic at a time.

All guide sections

Receivables Configuration and Setup

This domain tests where each Receivables setup object lives, what level it applies to, and which flag changes a processing behavior. Expect questions on system options, transaction types, transaction sources, AutoAccounting, payment terms, aging buckets, and reference data sets.

Setup hierarchy

Most behavior is configured per business unit in Manage Receivables System Options, including AutoInvoice defaults, receipt matching, over/under payment tolerances, and the accounts resolved by AutoAccounting. Reference data sets decide whether setup objects such as transaction types, AutoCash rules, and payment terms are shared across business units or isolated to one; assigning the same set to two business units makes the setup common to both.

Transaction types and AutoAccounting

A transaction type defines the class (invoice, credit memo, debit memo, chargeback, adjustment), the creation sign, whether Natural Application Only is enforced, and whether overapplication is allowed. AutoAccounting resolves the accounting flexfield from constants, variables such as Standard Line, Tax, Freight, and Receivable, or combinations; rules are selected by transaction source and transaction type.

Worked example

A business unit needs credit memos that can be applied to any open transaction, including another credit memo. Create a transaction type with creation sign Negative and clear Natural Application Only. If the flag stays checked, the credit memo can only be applied to transactions with the opposite sign, and the intended application fails validation.

Traps

  • Setup objects are not automatically global; a missing reference data set assignment makes a transaction type invisible in a new business unit.
  • Changing system options does not renumber or reaccount completed transactions.
  • Payment terms use installments and relative due dates, and the base date can come from the transaction date rather than the terms start date.