Add a Location Phone Number to Purchase Orders

A purchase order can contain the correct street address and still leave a driver unable to find the receiving dock. A shared location phone number can close that gap. The reporting change is modest, but the data ownership, catalog strategy, and regression testing determine whether it remains reliable after an Oracle quarterly update.

Choose the right contact source first

Do not begin with the RTF template. First agree on the business meaning of the number. A location record is often the best source for a stable receiving-desk or site number, but only when the location used on the purchase order represents the place that should answer a delivery question.

Clean the location data

Oracle’s current location view documentation includes TELEPHONE_NUMBER_1 and MAINPHONE_EXTENSION1. Before using them, identify who owns each location, confirm the correct number format, and test locations with no phone or extension. A report cannot repair inconsistent master data.

• Define whether the number belongs to the receiving dock, site switchboard, or another shared function.
• Use a consistent country-aware format and avoid ambiguous free-text extensions.
• Review inactive and effective-dated locations, duplicate names, and locations shared across business units.
• Restrict maintenance privileges and document the owner responsible for periodic review.

For related setup considerations, see Location Management.

Use a safe Custom catalog strategy

Do not edit the delivered Purchase Order Data Model directly. Oracle’s current guidance is to copy delivered analytics and reporting objects into the Custom catalog and point the copied report to the copied data model. This protects your version from being overwritten and makes the extension easier to identify and test.

1. Inventory the delivered objects. Locate the Purchase Order PDF Report and Purchase Order Data Model under the Procurement and Purchasing catalog areas. Record the delivered paths and current permissions.
2. Copy both objects. Save the report and data model into a controlled folder under Custom. Preserve access for the roles that generate and view purchasing documents.
3. Connect the copy. Confirm the custom report references the custom data model—not the delivered model and not an obsolete earlier copy.
4. Version the work. Retain the original RTF, sample XML, SQL change, test evidence, owner, and deployment date outside the catalog.

Oracle’s current references include configuring purchasing document reports and extending the outbound purchase-order message.

Extend the copied data model

Open the copied Purchase Order Data Model and inspect the actual data sets and aliases in your release. In the original 2023 implementation, the schedule or line query used the alias ShipToLocation, while the header query used ShipToLoc. Treat those as historical examples, not guaranteed names.

Add the phone and extension from the correct effective-dated location source to the data set needed by the layout. If a purchase order can contain multiple destinations, a header-only phone may be misleading; expose the value at schedule or line level when the business document needs that distinction.

Null-safe schedule example

CASE
  WHEN ShipToLocation.TELEPHONE_NUMBER_1 IS NULL THEN NULL
  WHEN ShipToLocation.MAINPHONE_EXTENSION1 IS NULL
    THEN ShipToLocation.TELEPHONE_NUMBER_1
  ELSE ShipToLocation.TELEPHONE_NUMBER_1
       || ' ext '
       || ShipToLocation.MAINPHONE_EXTENSION1
END AS ShipToScheduleFullPhone

Null-safe header example

CASE
  WHEN ShipToLoc.TELEPHONE_NUMBER_1 IS NULL THEN NULL
  WHEN ShipToLoc.MAINPHONE_EXTENSION1 IS NULL
    THEN ShipToLoc.TELEPHONE_NUMBER_1
  ELSE ShipToLoc.TELEPHONE_NUMBER_1
       || ' ext '
       || ShipToLoc.MAINPHONE_EXTENSION1
END AS ShipToHeaderFullPhone

The CASE expression avoids printing a stray “ext” when no phone or extension exists. Adapt concatenation and formatting to the database syntax and localization standards supported by the current data model.

Update and test the RTF layout

1. Run the copied data model with representative parameters and verify the new field in the Data output.
2. Save sample XML that includes a phone with an extension, a phone without an extension, no phone, and multiple ship-to locations.
3. Download the existing RTF and edit a copy with the supported Oracle Analytics Publisher desktop tooling. Older documentation may call this BI Publisher Desktop.
4. Place the field next to its location label so the relationship remains clear. Do not rely on color or visual position alone.
5. Preview with the sample XML, upload the new layout to the copied report, and confirm the intended layout is the default.

Keep the label and value readable when zoomed, avoid tiny type, preserve a logical reading order, and do not place critical information only in an image. For supplier notifications beyond the PDF, see Workflow Notifications.

Regression and governance checklist

• Test draft, approved, changed, canceled, and archived purchase-order output where applicable.
• Test a single destination and multiple line or schedule destinations; confirm the phone appears at the correct level.
• Test null phone, null extension, long international numbers, and locations with effective-date changes.
• Test multiple procurement business units, legal entities, languages, locales, currencies, and supplier communication methods used by the organization.
• Confirm roles can run the copied report and cannot inadvertently modify protected catalog objects.
• Compare email, printed, downloaded, archived, and change-order output so no channel uses a stale layout.
• After each quarterly update, compare the delivered data model and report with the custom copies and rerun the regression pack.
• Ask a keyboard and screen-reader user to verify the surrounding procurement process; make the PDF itself accessible wherever the output channel and tooling permit.

If the change requires additional descriptive fields rather than a location value, review Additional Data in Procure-to-Pay. Oracle also documents the current location fields in HR_LOCATIONS_ALL_X.

↑ Return to the start of the article