Self-Service Receiving and Notifications

When an organization orders something and the supplier delivers it, the requester must record the receipt. That small action connects physical delivery to invoice matching, liability recognition, accruals, buyer follow-up, and supplier payment. Yet receipt entry is easy to forget once the package is in hand.

Why receipt compliance breaks down

Requesters experience the delivery; Accounts Payable experiences the invoice hold. When those teams do not share the same work queue or vocabulary, an unrecorded receipt feels like someone else’s problem. The organization may then spend time chasing users, holding invoices, correcting accruals, or contacting suppliers about a problem that began with a missing transaction.

Use several paths to the same outcome

Redwood Self-Service Receiving

Oracle’s current Responsive Self-Service Receiving application uses the Redwood experience for the Orders to Receive and My Receipts workflows. Oracle’s 25B enhancements added table-based search results, configurable columns, spreadsheet export, additional search attributes, cross-business-unit search, and links to source documents and receipt transaction history.

Enabling the experience is more than changing a visual theme. Oracle documents receiving profile options, administrator search settings, initial ingestion, recurring ingestion for transactions created outside the application, transaction reasons, and role design. Advanced receivers may need configured roles containing privileges that are not delivered in a predefined job role.

• Enable the Redwood Self-Service Receiving pages through the documented receiving profile option.
• Plan privileges separately for requesters, preparers, advanced receivers, returns, corrections, inspection, and receipt-history access.
• Run the initial search-index ingestion and schedule ongoing ingestion where other pages, REST APIs, or file imports create receiving activity.
• Test mobile and narrow-screen behavior, keyboard operation, focus order, error messaging, and an alternative to camera-only scanning.

See Oracle’s current setup guidance for Responsive Self-Service Receiving and the 25B capability summary.

Turn invoice holds into visible requester actions

Current Responsive Self Service Procurement can mark requisition lines when an invoice hold requires action. Oracle documents the Update Requisition Line Action Required Code scheduled process, which can identify lines affected by order- or receipt-related quantity and amount holds. The requisition line’s action-required value can then guide the requester toward a receipt or purchase-order change.

For a receipt shortfall, the applicable scenario includes an expense-destination purchase-order line, three-way match approval, direct-delivery receipt routing, and a quantity- or amount-received invoice hold. From My Requisitions or Requisition Details, a permitted user can confirm receipt in full, receive up to the invoiced quantity, or continue to My Receipts when more detail is needed.

Review Oracle’s current instructions for resolving requisition lines with invoice holds.

Configure Confirm Receipts notifications deliberately

The Confirm Receipts scheduled process generates workflow notifications for eligible past-due purchase orders and transfer orders. Oracle recommends scheduling it according to volume—often daily—to create timely notifications. Access to the process and the notification itself depends on the appropriate privileges.

For purchase orders, the documented workflow focuses on direct-delivery expense items and three-way matching. A notification may be generated after the need-by date has passed or when an invoice matched to the line is on an applicable receiving hold. Transfer-order receipt confirmation has its own eligibility and profile-option requirements.

Oracle’s scheduled-process documentation states that notifications expire after 15 days by default, then escalate to the requester’s manager, and expire after an additional week. Treat these as configurable product behavior to verify in the release and workflow deployed in your environment.

See Oracle’s documentation for the Confirm Receipts scheduled process and notification responses.

Make every response understandable

The choices are convenient, but they are not interchangeable. “Receive in full” is not a shortcut for “close the invoice hold.” Users need enough context to compare what was ordered, delivered, and invoiced before making a selection. When lots, serials, inspection, project details, attachments, or other receiving attributes are required, route the user to the detailed receiving experience.

• Use plain-language instructions that distinguish physical delivery from invoice status.
• Show purchase order, supplier, line, item or description, ordered amount, invoiced amount, and need-by date.
• Explain when “receipt up to invoiced” is appropriate and when it could create an incorrect receipt.
• Provide a clear exception path for damaged, partial, substituted, disputed, or unidentified deliveries.
• Do not rely on color alone to distinguish overdue, invoiced, held, or complete statuses.

Govern customizations and escalation

The original article described hiding a notification response by changing access to the ConfirmReceiptFYIAction task. Because workflow names, supported configuration points, and update behavior can change, treat that technique as historical—not as a current implementation instruction. Validate any BPM change in a current nonproduction pod, document the business reason, test all personas and escalation paths, and regression-test after quarterly updates.

A stronger implementation also defines ownership:

1. Requester: confirms what physically arrived and records timely exceptions.
2. Buyer: resolves supplier and order issues, investigates “did not receive,” and re-notifies appropriately.
3. Accounts Payable: validates invoices, manages holds, and distinguishes a true receipt problem from an invoice or order problem.
4. Receiving administrator: maintains profiles, scheduled processes, indexing, roles, reasons, and workflow health.
5. Process owner: monitors aging and repeat failures, coordinates training, and approves changes to controls.

Implementation checklist

• Map direct-delivery, inventory, transfer-order, amount-based, lot-, serial-, and inspection-controlled scenarios separately.
• Confirm match approval levels, receipt routing, destinations, tolerances, invoice-hold behavior, and who may receive on behalf of another person.
• Enable and test Redwood Self-Service Receiving profile options, search indexes, ingestion jobs, transaction reasons, and security.
• Schedule Confirm Receipts and action-required updates in the correct sequence for the expected transaction volume.
• Test notification actions, reassignment, buyer escalation, manager escalation, expiration, duplicate prevention, and resolved-hold cleanup.
• Measure aging unreceived lines, invoice holds attributable to missing receipts, response time, escalation volume, incorrect receipts, and repeat noncompliance.
• Provide accessible instructions, keyboard-operable workflows, visible focus, descriptive links, and non-email access to the same actions.

↑ Return to the start of the article