Results for “write_off_code”

2 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PO_ACCRUAL_WRITE_OFFS_ALL is a Purchasing (PO) module table that stores records of accrual write-offs. In Oracle E-Business Suite, perpetual accruals are created when receipts are recorded against purchase orders and are relieved when the corresponding supplier invoices are matched and accounted. When an accrual cannot be matched to an invoice — for example, because of a quantity shortfall, an unreconciled receipt, or inactivity in the receiving clearing account — the accrual must be manually or systematically written off. This table captures the complete audit trail of those write-off transactions, including the receipt or invoice that caused the accrual, the accrual account affected, the amount written off, and the accounting period and GL date on which the adjustment posts.

Within the Receipt Accounting (formerly Purchasing) sub-ledger, the table functions as an operational and reporting repository for reconciliation activity. Its heuristic Data Vault classification, mined from its foreign-key structure, is link — a modeling suggestion that reflects its role as a transactional intersection joining purchasing, receiving, inventory, work-in-process, payables, and general ledger entities. This classification is not an Oracle-declared designation.

Key Information Stored

The table is owned by the PO schema and, per the documented 12.2.2 physical schema, contains 56 columns. The single unique index, PO_ACCRUAL_WRITE_OFFS_U1, is defined on WRITE_OFF_ID, making that column the primary business-key candidate for identifying each write-off record. WRITE_OFF_ID should be distinguished from any surrogate sequencing, but in practice it serves as the table's unique identifier for each write-off event.

Common Use Cases and Queries

Typical uses include period-end reconciliation of the Purchasing accrual (receiving clearing) account, analysis of write-off volumes by reason or vendor, and investigation of unmatched receipts or invoices that generated write-offs. A common reporting query joins to PO_HEADERS_ALL and PO_VENDORS to present write-offs by supplier and period:

  • Accrual reconciliation: aggregate TRANSACTION_AMOUNT by PERIOD_NAME and ACCRUAL_ACCOUNT_ID to reconcile write-offs against GL balances.
  • Write-off analysis: GROUP BY REASON_ID or WRITE_OFF_CODE to identify recurring causes of accrual relief.
  • Vendor exposure: join VENDOR_ID to PO_VENDORS to report write-offs by supplier.
  • Document tracing: join PO_TRANSACTION_ID to RCV_TRANSACTIONS and INVOICE_ID to AP_INVOICES_ALL to trace the full receipt-to-invoice-to-write-off chain.
SELECT w.PERIOD_NAME, w.VENDOR_NAME, w.ACCURAL_CODE,
       SUM(w.TRANSACTION_AMOUNT) write_off_amt
FROM   PO.PO_ACCRUAL_WRITE_OFFS_ALL w
WHERE  w.PERIOD_NAME = :period
GROUP  BY w.PERIOD_NAME, w.VENDOR_NAME, w.ACCURAL_CODE;

Related Objects

The table is densely connected to core procurement, receiving, inventory, payables, and accounting entities through the documented foreign keys:

  • PO_HEADERS_ALL, PO_LINES_ALL, PO_DISTRIBUTIONS_ALL — joined via PO_HEADER_ID, PO_LINE_ID, and PO_DISTRIBUTION_ID to identify the originating purchase order.
  • RCV_TRANSACTIONS — joined via PO_TRANSACTION_ID for the receipt that created the accrual.
  • MTL_MATERIAL_TRANSACTIONS — joined via INV_TRANSACTION_ID for the inventory movement.
  • WIP_TRANSACTIONS — joined via WIP_TRANSACTION_ID where accruals relate to work-in-process issues.
  • AP_INVOICES_ALL — joined via INVOICE_ID for the matched invoice.
  • GL_CODE_COMBINATIONS — joined via ACCRUAL_ACCOUNT_ID to resolve the accrual account.
  • PO_VENDORS — joined via VENDOR_ID for supplier information.
  • MTL_TRANSACTION_REASONS — joined via REASON_ID for the write-off reason.