Last updated
Modernize your Oracle ADF non-PO coding form
Every coding rule change is a development project. Modernize the non-PO coding experience without an ADF rebuild — same EBS or Fusion integration, AP-team-configurable UI.
What this is
The ADF non-PO coding form, in plain language
"Our non-PO coding form is built in Oracle ADF and customizations turn every small change into a development project." That is the verbatim sentence we hear most often from AP and Finance leaders running a WebCenter AP implementation. The non-PO coding form is the page AP users open when an invoice has no purchase order to match against, to assign charge accounts, cost centers, projects, funds, and other segment values for posting into Oracle EBS Payables or Oracle Fusion Cloud Payables.
In a typical WebCenter AP implementation, that page is built in Oracle Application Development Framework (ADF) — JSF-based UI, built in JDeveloper, deployed to WebLogic Server. Customers have customized it over the years with fund accounting, encumbrance, defaulting, and validation logic that ended up encoded in Java backing beans rather than configuration. That is what makes every change a development cycle.
Modernization here means replacing the ADF coding UI with a modern, AP-team-configurable coding and approval experience — while preserving the Oracle integration layer (EBS Payables Open Interface or Fusion FBDI / OIC REST). The AP team configures coding rules through an admin UI rather than through a developer pulling JDeveloper out of mothballs.
What it is
What the ADF non-PO coding form actually is
Four facts that frame the engagement. Each one shapes what the replacement project has to handle.
Built on Oracle ADF / JSF
The non-PO coding form in a typical WebCenter AP implementation is an Oracle Application Development Framework (ADF) page — JSF-based UI, built in JDeveloper, deployed to WebLogic Server alongside the WebCenter Imaging and SOA stack.
Codes invoices with no PO match
When there is no PO to match an invoice against, the AP user opens the coding form to assign charge accounts, cost centers, projects, funds, departments, locations, and any other dimensional posting required by the GL chart of accounts.
Customized over years
On most engagements the form has been customized over years — fund accounting rules, encumbrance logic, segment defaulting, validation hooks, custom Java in backing beans, lookup tables specific to that customer's chart of accounts.
Coupled to SOA composites
Submission from the form usually routes through SOA composites for approval workflow and on to EBS Payables Open Interface or Fusion FBDI / OIC for posting. Changes ripple into those downstream components.
Why customers raise it
Why this is the most painful piece of WebCenter AP
Across the customers we work with, the non-PO coding form is consistently the piece that comes up first. Four reinforcing reasons.
Changes need senior ADF hands-on the stack
Working confidently in JDeveloper, ADF Faces, ADF Business Components, and ADF Task Flows takes senior, hands-on experience. The customers we talk to describe long lead times to line up someone who can safely touch the page, and small changes waiting on that availability.
Every coding rule change is a development cycle
Adding a new fund, changing a default cost center, updating a validation rule, or extending segment defaulting almost always requires opening JDeveloper, editing the page or a backing bean, rebuilding the EAR, and redeploying to WebLogic. AP teams cannot self-serve.
The UX has not aged well
ADF Faces pages designed in the early 2010s show their age — dense tables, limited keyboard support, browser compatibility quirks, and no real mobile story. AP teams that have adopted modern tooling elsewhere notice the gap when they enter the coding step.
Tight coupling to downstream SOA composites
The form's submit handler, payload structure, and validation rules are often woven into SOA composites that route the coded invoice forward. Touching the form without an SOA-aware review risks breaking approval routing, encumbrance checks, or posting.
The definition
What "modernization" actually means here
Modernization of the ADF non-PO coding form is not a rewrite of the page in a newer ADF version, and it is not a UI skin on top of the same backing beans. It is the replacement of the ADF UI with a modern, configurable coding form — a coding experience where the rules live in configuration that the AP team can edit, not in Java code that has to be rebuilt and redeployed.
The Oracle integration layer is preserved. Coded invoices still post to Oracle EBS Payables via Payables Open Interface or to Oracle Fusion Cloud Payables via FBDI or OIC REST. The ERP system of record, audit trail, segregation of duties, and security model stay where they are. The change is at the coding-and-approval layer, not at the ERP layer — and the result is that the AP team owns coding-rule changes instead of queuing them behind a JDeveloper sprint. See ERP-native integration for how the integration layer is structured.
Common scenarios
Where customers are when they raise this
Four scenarios we hear repeatedly. The shape of the engagement is different in each one, but the underlying need is the same: stop treating coding rule changes as a development project.
Every small change becomes a development project
"Our non-PO coding form is built in Oracle ADF and customizations turn every small change into a development project." This is the verbatim language we hear most often. AP wants a new fund or a tweaked default and the answer comes back as a JDeveloper sprint.
EBS to Fusion migration where the ADF form is the blocker
The ERP team has a path from EBS to Fusion Cloud — but the ADF coding form is so customized that nobody can confidently answer what happens to it on the other side. The non-PO coding experience becomes the long pole that delays the migration plan.
Fund accounting or encumbrance rules outgrew the form
Public-sector, healthcare, and education customers add new funds, grants, and encumbrance scenarios over time. The original ADF design assumed a simpler model. Each new requirement gets bolted on as another customization until the form is fragile to change.
Browser compatibility forcing an emergency JDeveloper rebuild
A browser update or a managed-endpoint policy change breaks the ADF page rendering. The customer suddenly needs the ADF skill set on short notice, just to keep the existing form running, with no improvement in capability.
The delivery approach
How EZ Cloud delivers the replacement
Six steps. The reverse-engineering of the existing ADF form is the part most consulting partners cannot do — the rest of the project depends on getting that inventory right.
Read the existing ADF form configuration
Andrew reads the existing ADF page, backing beans, ADF Business Components, custom Java, and any iDoc Script or workflow hooks that surround it. Extracts the coding rules, defaulting logic, validation behavior, and approval routing — captured as a structured inventory the customer keeps regardless of next step.
Map coding rules to the EZ Cloud configurable coding engine
Charge account segments, cost center defaulting, fund and project lookups, encumbrance rules, dimensional posting, and validation behavior are mapped into the EZ Cloud coding configuration. Where the ADF page held rules in custom Java, the equivalent rule becomes an AP-administrator-editable configuration entry.
Preserve the EBS or Fusion integration pattern
For EBS customers, the EZ Cloud platform writes the coded invoice to Payables Open Interface using the same column conventions the existing implementation uses. For Fusion customers, the platform posts via FBDI or REST through Oracle Integration Cloud — the same Oracle-supported interfaces the ERP team already audits.
Re-wire approval routing
Where the existing implementation routed through SOA composites, the EZ Cloud configurable approval engine takes over the routing decision and the SOA layer is either retired or simplified. Where the customer wants to keep an existing approval composite, the EZ Cloud platform can hand off to it.
Parallel run during UAT
The existing ADF form and the new EZ Cloud coding experience run in parallel during UAT. AP users code a sample set in both, and the resulting GL distribution lines are reconciled. Cutover happens only after end-to-end posting validation is complete.
Hand the configuration to the AP team
After cutover, the AP team owns the coding configuration through an admin UI. Adding a fund, updating a default, or extending a validation rule no longer requires JDeveloper, a developer, or a redeploy.
What does not change
What stays the same after the replacement
Replacing the ADF coding UI does not require touching the ERP system of record, the audit trail, segregation of duties, the integration interface, or the security model. Those are explicitly preserved.
ERP system of record
Oracle EBS or Fusion remains the system of record. Vendor master, GL, payment processing, and period close stay where they are.
Audit trail and posting integrity
Every coded invoice carries the same audit detail — who coded it, who approved it, when it was posted, and the full coding history. The audit story does not weaken in the move.
Segregation of duties and security model
Roles, segregation between coder and approver, and the existing security boundaries are preserved. EZ Cloud roles map to the existing customer security model rather than replacing it.
Oracle-supported integration interfaces
Integration into the ERP uses Oracle-supported interfaces — Payables Open Interface for EBS, FBDI and OIC REST for Fusion. No custom database writes, no unsupported back-channel.
How EZ Cloud engages on ADF coding form replacement
Engagement options
Two delivery modes. Standard Consulting is the default for customers who want a fixed-fee replacement project. Forward Deployed Engineering is the right fit when the existing ADF page is so heavily customized that reverse-engineering is the load-bearing part of the project.
Tier 1 · ADF Coding Form Assessment
Fixed-fee read of your existing ADF page
Andrew reads your existing ADF non-PO coding form directly — page, backing beans, ADF Business Components, custom Java, surrounding SOA composites — and delivers a structured inventory of coding rules, defaulting behavior, validation hooks, and approval routing. The inventory is yours to keep regardless of which delivery partner you choose next.
Tier 2 · Standard Consulting — Fixed-fee replacement project
Scoped ADF-to-EZ-Cloud coding form replacement
A defined-scope project that takes your existing ADF non-PO coding form, maps the coding rules into EZ Cloud configuration, preserves the EBS Payables Open Interface or Fusion FBDI / OIC integration pattern, runs in parallel during UAT, and hands the coding configuration to your AP team at cutover. Project-based, founder-led, scoped to a defined outcome.
Tier 3 · Forward Deployed Engineering
Heavy customization reverse-engineering
For implementations where the ADF page has been customized over many years — extensive fund accounting, encumbrance, custom Java in backing beans, intricate validation chains — Forward Deployed Engineering is the right mode. Andrew works embedded with the customer team to reverse-engineer the page, extract the rules, and rebuild on EZ Cloud configuration. Time-and-materials with a defined reverse-engineering milestone before the build phase begins.
Tier 4 · Strategic Advisory Retainer
Founder-level guidance during the decision window
For customers working through the ADF coding form decision in the context of a larger WebCenter or EBS-to-Fusion conversation, a monthly retainer with Andrew provides strategic guidance on architecture choices, sequencing, and how the coding form decision interacts with the December 2026 12c support decision and the 14c upgrade path.
Engagement pricing is established per situation on a Decision Call.
Free resource
The Oracle WebCenter AP December 2026 Decision Guide
The ADF non-PO coding form decision rarely sits on its own — it usually shows up alongside a 12c support, 14c upgrade, or EBS-to-Fusion conversation. The Decision Guide is the structured framework for the four forward paths and how the coding form decision fits inside them.
Read the Decision GuideWho has done this before?
20+ years of WebCenter delivery — the engagement history
Engagements Andrew Blackman has personally delivered across 25 years of Oracle consulting — most recently under an Oracle Consulting Services contract. This is the depth behind every EZ Cloud engagement.
Via Rail
2025–2026Transportation
WebCenter Forms Recognition AP automation on OCI, integrated with Oracle EBS R12 and Fusion Cloud ERP — delivered under an Oracle Consulting Services contract. 17 WFR customizations across PO and non-PO invoices.
US House of Representatives
2017Government
Upgraded heavily customized Oracle Document Capture and WFR 10gR3 to WebCenter Enterprise Capture 12.2.1.2 and WFR 11.1.1.9, replacing customizations with out-of-the-box Capture functions.
State of Alaska
2018–2019Government
Migrated WebCenter Content and SOA from on-premises to Oracle Cloud — 18+ million content items — including the 11g to 12c upgrade and a hybrid Kofax-to-Oracle-ERP integration.
ASML (Cymer)
2020–2024Manufacturing
Four-year migration of the on-premises WebCenter and SOA estate to Oracle Integration Cloud, VBCS, and Oracle Content Management for AP automation.
Archer Daniels Midland
2016–2017Manufacturing
Functional design for the global WebCenter ECM platform — metadata and security models, server sizing, GDPR considerations, and the WebCenter Imaging 11g to 12c upgrade path.
Harvard Pilgrim Healthcare
2016–2017Healthcare
WebCenter Content, Sites, and Portal upgrades from 11.1.1.9 to 12.2.1.2, Solaris-to-Linux migration, and Secure Enterprise Search integration.
Experian
2015–2016Financial services
Clustered Linux implementation of WebCenter Content, Imaging, Capture, BPM, and SOA, plus the Stellent IBPM to WebCenter migration design.
Equifax
2013–2014Financial services
AP invoice automation with Oracle EBS R12 integration — functional and technical designs through development and production implementation.
Marsh & McLennan
2013Financial services
Fully automated AP invoice solution on EBS R12 — WebCenter Capture, Imaging, Content, Forms Recognition, and SOA — mapped from legacy Markview 170 processes.
Blue Cross Blue Shield (FCSO)
2011–2013Healthcare
WebCenter Capture, Content, Imaging, and SOA implementation — commit/import servers, file cabinets, and scan profiles.
Metropolitan Transportation Authority (NY)
2009–2011Government
Architected the MTA Business Service Center shared-services ECM on Oracle UCM and Document Capture, with AP invoice automation integrated to PeopleSoft, through go-live.
Philadelphia Housing Authority
2012–2014Public housing
FIPSA-based AP invoice automation with PeopleSoft integration — WebCenter Content, Imaging, BPEL/SOA, Capture, and Managed Attachments for HR and CRM.
Prince George's County Public Schools
2014–2015K-12 education
Managed Attachments for HR plus AP invoice automation including WebCenter Forms Recognition, on an AXF-based EBS integration.
US Department of Agriculture (NITC)
2005–2009Federal government
Stellent 7.51 to Oracle UCM 10gR3 upgrade and multi-year content-server administration — the Stellent-era roots of the WebCenter practice.
Not ready for a call? Start with the engagement overview.
Get the one-page overview of how EZ Cloud engagements work — assessment tiers, what each one delivers, and how the Decision Call fits. Andrew Blackman sends it personally within one business day.
Common questions
Direct answers on the ADF non-PO coding form
Talk through your ADF non-PO coding form
A 30-minute Decision Call with Andrew Blackman, founder of EZ Cloud and a 25-year Oracle WebCenter specialist with 20+ years on the ADF, SOA, and WebCenter Imaging stack. Walk through your existing ADF coding form, the surrounding workflow, and the replacement options in the context of your specific implementation.