Search Results pjm_borrow_paybacks_u1




Overview

PJM.PJM_BORROW_PAYBACKS is a transactional table in the Oracle EBS Project Manufacturing (PJM) application, storing the results of inter-project borrow and payback processing. When material is transferred from a lending project to a borrowing project in an inter-project borrow transaction, a subsequent payback transaction returns that material. PJM_BORROW_PAYBACKS captures the allocation of each payback transaction against outstanding borrow transactions, using a FIFO (first-in, first-out) algorithm to determine which borrow lots are consumed first. The Cost Processor reads this allocation data to generate the correct accounting entries for the payback transaction, ensuring that costs are reversed against the originating borrow distributions.

From a heuristic Data Vault classification perspective, this object is best modeled as a link table. Its primary key is a composite of two transaction identifiers — BORROW_TRANSACTION_ID and PAYBACK_TRANSACTION_ID — and it resolves the many-to-many relationship between borrow and payback events, with PAYBACK_QUANTITY acting as the non-key descriptive measure of that association. It carries no independent business identity of its own; its purpose is to record the intersection of two transactional hubs.

Key Information Stored

The composition primary key is (PAYBACK_TRANSACTION_ID, BORROW_TRANSACTION_ID), defined by the unique index PJM_BORROW_PAYBACKS_U1 and the backing PJM_BORROW_PAYBACKS_PK constraint. These two columns are the business-key candidates and also serve as the foreign keys that anchor the table to MTL_MATERIAL_TRANSACTIONS and PJM_BORROW_TRANSACTIONS respectively.

Common Use Cases and Queries

The most frequent use is reconciling borrow/payback balances for inter-project material transfers and tracing how a payback was distributed across open borrow lots. The FIFO allocation means a single payback may produce multiple rows, one per borrow transaction touched.

Allocation detail for a payback:

SELECT BORROW_TRANSACTION_ID, PAYBACK_QUANTITY
FROM   PJM.PJM_BORROW_PAYBACKS
WHERE  PAYBACK_TRANSACTION_ID = :p_payback_txn_id;

Remaining payback quantity per lending project (uses the N2 index):

SELECT LENDING_PROJECT_ID, SUM(PAYBACK_QUANTITY)
FROM   PJM.PJM_BORROW_PAYBACKS
GROUP  BY LENDING_PROJECT_ID;

Cost Processor debugging — joining to the borrow side to inspect the originating borrow and its payback coverage:

SELECT b.BORROW_TRANSACTION_ID, p.PAYBACK_TRANSACTION_ID,
       b.BORROW_QUANTITY, p.PAYBACK_QUANTITY
FROM   PJM.PJM_BORROW_TRANSACTIONS b,
       PJM.PJM_BORROW_PAYBACKS p
WHERE  b.BORROW_TRANSACTION_ID = p.BORROW_TRANSACTION_ID
AND    p.BORROW_PROJECT_ID = :p_project_id;

Typical reporting includes borrow/payback summary by project and task, aged open borrow analysis, and audit queries resolving which concurrent request created each allocation row.

Related Objects

  • PJM_BORROW_TRANSACTIONS — joined on BORROW_TRANSACTION_ID; the originating borrow record.
  • MTL_MATERIAL_TRANSACTIONS — joined on PAYBACK_TRANSACTION_ID; the inventory payback transaction header.
  • PA_PROJECTS_ALL — referenced twice, via BORROW_PROJECT_ID and LENDING_PROJECT_ID.
  • PA_TASKS — referenced twice, via BORROW_TASK_ID and LENDING_TASK_ID.
  • PJM Cost Processor and inter-project borrow/payback concurrent programs — populate and consume this table via the extended Who columns (REQUEST_ID, PROGRAM_ID).

Because the table is a pure link structure, any query reconstructing cost or inventory impact must join outward to both the borrow and material transaction hubs rather than reading it in isolation.