MetroPCS — Custom Auto-Req Projects & XML Procurement Portal Implementation

Executive Summary

MetroPCS was a high-growth prepaid wireless carrier requiring Oracle EBS procurement capabilities that matched the pace and structure of its aggressive network expansion strategy. Standard Oracle Purchasing workflows did not accommodate the project-based procurement model the business relied on — where capital expenditures and operational purchases were driven by network rollout projects, not by individual department requisitions.

This engagement delivered a custom Auto-Req Projects feature — an Oracle extension that automatically generated requisitions from approved project budgets — alongside an XML-based procurement portal, Discoverer reporting, and DataLoader-based data migration. The result was a procurement system tightly aligned to MetroPCS's capital-intensive, project-driven operating model.

With 2,642 files across seven work streams and over two years of engagement duration, this was the second-largest client engagement in the practice portfolio, reflecting both the complexity of telecom procurement and the iterative refinement required to get custom Oracle development right.

Engagement Context

Prepaid wireless carriers in the early 2000s were building networks at speed — acquiring tower leases, deploying equipment, and standing up retail locations faster than their back-office systems could support. MetroPCS's purchasing process had grown organically and was fragmented across spreadsheets, email chains, and informal approval processes that created audit risk and budget overruns.

The core business challenge was this: MetroPCS organized its spending around network projects (e.g., a new market launch or a tower cluster buildout), but Oracle's standard requisition model is department-centric, not project-centric. Every purchase in a project-driven environment has a project code, a budget line, and a committed cost — none of which Oracle standard PO handles natively without significant configuration or custom development.

The decision to build the Auto-Req Projects feature rather than use Oracle Projects or iProcurement was driven by cost and timeline constraints — a targeted custom solution was faster to deploy than a full Oracle Projects implementation and more tailored to the specific MetroPCS workflow.

Oracle Implementation Scope

Custom Auto-Req Projects Feature

The centerpiece of the engagement was a custom database-driven mechanism that read approved project budget lines and automatically generated Oracle requisitions in the PO module. This eliminated the manual step of having project managers create requisitions from memory or spreadsheet — the system created them from the approved budget, complete with project cost coding, supplier information, and required-by dates.

Custom tables stored the project-to-requisition mapping. A scheduled concurrent program processed new budget approvals and created corresponding requisitions. Exception handling managed budget overages, missing supplier assignments, and approval hierarchy gaps.

XML Procurement Portal Integration

An XML-based interface was built to allow requisitions to be submitted from an external procurement portal directly into Oracle PO. The integration handled XML document transformation, validation against Oracle business rules, and status callback to the portal on approval or rejection. This was an early example of what would later become Oracle Purchasing Command Center capabilities.

Discoverer Reporting

Oracle Discoverer workbooks were built to support purchasing analysis: open PO reports, requisition aging, budget vs. actual by project, and supplier performance dashboards. Discoverer was the standard Oracle BI tool of the era and required End User Layer (EUL) configuration on top of Oracle's standard business areas.

DataLoader Migration

Historical purchase data, open POs, and supplier master records were migrated from legacy systems using Oracle DataLoader (SQL*Loader control files with custom transformation scripts), ensuring no data gaps at go-live cutover.

Methodology Applied

The standard CRP2 cycle was run in parallel with the custom Auto-Req development track — an approach that creates efficiency but requires disciplined integration checkpoints. Standard Oracle modules (PO standard flows, AR, GL) were validated through CRP2 test scripts while Auto-Req development proceeded independently and was integrated into the test environment for a final combined regression test before go-live.

1. Standard Module CRP2: PO, AR, GL configured and tested using standard Oracle CRP2 methodology with business scenario-based test scripts.
2. Custom Development: Auto-Req Projects feature designed, built, and unit-tested in a separate development instance.
3. XML Portal Integration Build: XML interface designed and built with external portal team; integration testing conducted in shared test environment.
4. Combined Regression Test: Full end-to-end test of Auto-Req → PO → AP → GL flow, including XML portal submission scenarios.
5. DataLoader Validation: Mock cutover executed to validate data migration completeness and accuracy before production cutover.

Key Deliverables

Technical Architecture

The Auto-Req Projects custom feature introduced three new database objects into the Oracle schema: a project budget staging table (populated by the project approval workflow), a requisition generation concurrent program (PL/SQL package executed on a scheduled basis), and an exception log table (capturing failures for review and manual resolution). These objects operated alongside standard Oracle PO tables — they did not modify Oracle's standard code, preserving upgrade compatibility.

The XML portal integration used Oracle's standard PO public API (PO_REQUISITION_IMPORT) as the insertion point — XML documents were parsed, transformed, and passed to the standard Oracle import program rather than direct table inserts. This approach maintained data integrity and leveraged Oracle's built-in validation.

Critical Challenges & Resolutions

Challenge 1: Project Budget Synchronization Timing

The Auto-Req concurrent program ran on a schedule, creating a timing gap between budget approval and requisition availability. Project managers expected immediate requisition creation upon budget approval. Resolution was a hybrid approach: near-real-time trigger for high-priority projects (manual concurrent program submission) combined with scheduled processing for standard projects — reducing the perceived delay to minutes rather than hours.

Challenge 2: XML Schema Version Management

The external procurement portal evolved its XML schema during development, requiring the Oracle-side transformation logic to be updated multiple times. Resolution was establishing a schema version control protocol and a formal change notification process — any portal-side schema change required 72-hour advance notice and a coordinated release to the Oracle environment.

Challenge 3: Attachment Handling for Purchase Orders

Project managers required supporting documentation (scope documents, vendor quotes) to be attached to purchase orders. Oracle's standard attachment framework requires manual upload; the XML portal needed to pass document references programmatically. The resolution used Oracle's FND_ATTACHED_DOCUMENTS API to create attachments from document URLs passed in the XML payload — avoiding file transfer complexity while maintaining document linkage.

Challenge 4: Discoverer Performance on Large Data Sets

Discoverer workbooks querying historical PO data performed poorly as the data volume grew. Resolution involved creating summary-level database views, adding composite indexes on frequently filtered columns, and implementing workbook-level row fetch limits with instructional notes guiding users to apply filters before running reports.

Consultant Insights

Reusable Patterns

• Project-Driven Procurement Design Template: The Auto-Req architecture (budget staging table → concurrent program → Oracle PO import API) is reusable for any client whose procurement is project-budgeted rather than department-budgeted.
• XML Integration via Oracle Public API: Using Oracle's standard public APIs (rather than direct table inserts) for all integrations is the correct long-term approach. This engagement validated the pattern for PO requisition import specifically.
• Custom Objects Register: The custom objects documentation standard developed here (object name, purpose, schema owner, upgrade notes) should be a mandatory deliverable on any engagement with Oracle customization.
• DataLoader Validation Protocol: The mock cutover approach — full DataLoader execution in test, comparison of record counts and key field values against source — should be standard practice on any data migration engagement.

Lessons Learned

Related Engagements