This post is for anyone who designs, configures, or troubleshoots these flows. I'll walk through what intercompany is, the three most common types and when each applies, why it's genuinely hard, how to validate your setups, and how we cut 67% of the steps out of the most manual part using Oracle APEX. 👊🏼 🏆 💪🏼

3 Key Takeaways ✍️

1. Oracle ERP supports numerous intercompany types. It's essential to choose the right one for your scenario. Else, accounting, inventory and operational problems can compound quietly for years. This is painful to undo.

2. The most common intercompany GL failure is not a missing setup, but a wrong pointer. One misconfigured Transaction Type reference cascades into multiple wrong accounts across AR, AP, and the GL. You won't see it until you run the full cycle and trace back the actual entries.

3. Intercompany elimination only works if Intercompany (IC) Receivable, IC Payable, IC Revenue, and IC COGS are on dedicated, segregated accounts. If you mix them with your external AR/AP and sales accounts, elimination becomes a manual exercise every month end close cycle.

What Intercompany Is and Why It Exists

When two operating units (OUs) or legal entities inside the same parent company buy or sell from each other, those transactions still have to look "arm's length" on each entity's books — as if they were dealing with an outside, unrelated company.

One OU ships the product and records a receivable and revenue. The other OU receives the product and records a matching payable and inventory cost.

At consolidation, it should all zero out. IC Receivable nets against IC Payable. IC Revenue nets against IC COGS.

This is the theory at least. But here's why it is harder in practice.

Many Types of Intercompany

This is where most implementations stumble. In Oracle ERP, both R12 and Fusion, there are over seven distinct types. Each one triggers different accounting flows, setup dependencies and operational behaviors. I highlight the most commonly used below.

1. Internal Requisition / Internal Sales Order (IR/ISO) (also referred to as Transfer Orders)

This is used for inventory replenishment across operating units. For example, if one OU needs stock, the other ships it. The receiving OU creates an Internal Requisition. The ERP then converts it to an Internal Sales Order in the shipping OU. The shipping OU picks, packs, ships, and invoices the receiving OU at a transfer price through the IC invoicing programs.

This is the most common type in manufacturing and distribution environments.

2. External Drop Ship

A customer-facing sales order is fulfilled directly by an external supplier who ships to the customer. The OU does not need to touch the inventory. Intercompany accounting flows through the purchase order receipt instead of the sales order shipment.

3. Internal Drop Ship

A customer-facing sales order is fulfilled by another internal operating unit, which ships directly to the end customer. The selling OU books the external sale and owns the customer relationship. The fulfilling OU ships the product and invoices the selling OU at transfer price. There are two shipments and two invoices here, but also, two profit margins to watch and verify.

⚠️ The distinction between Type 1 and Type 3 matters more than most teams realize. In Type 1, the receiving OU is the end customer. In Type 3, there is an external customer beyond the receiving OU. The shipping network configuration, the Intercompany price list, and the revenue recognition events are all different. Careful with the configuration.

Why Intercompany Is Genuinely Hard

1. It's a long, multi-step, multi-domain chain.

Intercompany is one of the more complex cross-module configurations in ERP. It touches at least seven modules before a single transaction posts: Inventory, Costing, Order Management, Receivables, Tax, Payables and Accounting.

Intercompany accounting in Oracle ERP is driven by a sequence of interdependent setups: the Intercompany (IC) Relations configuration, the shipping network, the OM Transaction Type, Sub-ledger Accounting (SLA) rules, the AP setup in the receiving OU, and the IC price list. Each one feeds the next.

A mistake at any point in the chain shows up silently in the GL output. There is no single "intercompany setup" screen. It is spread across Inventory, Order Management, Receivables, Payables, General Ledger, etc. You have to understand all modules to trace it correctly.

2. The errors do not throw out error messages.

Unlike a missing required field that throws a validation error, a wrong account configuration in intercompany does not stop the process. The IC programs run, the invoices get created and the GL entries post. You are not informed it may be to the wrong accounts until it's too late.

On a recent engagement, we ran the IC cycle end-to-end. It completed without a single error message. When we pulled Account Inquiry, we found IC revenue posting to an external sales account and IC payables hiding inside an inventory accrual account. Nothing indicated anything was broken. Everything just pointed to the wrong place.

3. The return leg is almost always an afterthought.

Most teams configure the outbound IC flow and then discover at the first return that the return path uses a different network that does not trigger IC invoicing. Outbound and return shipping networks are frequently asymmetric. Consider and design the return flow before go-live.

The Validation Checklist

The only way to know your intercompany setup is correct is to run the full IC cycle in a test environment and trace the actual GL entries. Here is what to look for:

1. Amounts match. The IC AR invoice amount in the shipping OU must equal the IC AP invoice amount in the receiving OU, both at the transfer price from the IC price list. Any difference indicates a setup or perhaps a timing issue.

2. Accounts are correct. Trace every entry in the GL Account Inquiry. Compare what actually posted against what's configured in IC Relations and the Sub-ledger Accounting (SLA). If they don't match, go back and retrace the full chain.

3. Currency and Foreighn Exchange (FX) rate. If the IC invoice is in a different currency than the functional currency of either set of books, verify that the conversion rate matches what your IC Currency Conversion profile option specifies. FX mismatches create reconciliation differences that are hard to find.

4. Same GL period. The AR and AP entries must post in the same accounting period. Timing differences, such as where the AR side posts in period 1 and the AP side posts in period 2, create reconciliation issues for that period.

5. Dedicated IC accounts throughout. IC Receivable must be segregated from external AR. IC Payable must be segregated from external AP. IC Revenue must be segregated from third-party sales. IC COGS must have its own account. Mixing any of these with external accounts makes elimination at each month end a manual journal entry exercise.

6. Elimination-ready. IC Receivable (shipping OU) + IC Payable (receiving OU) must net to zero. IC Revenue (shipping OU) + IC COGS (receiving OU) must net to zero.

Any non-zero balance on that last check will surface up at time of consolidation. ⚠️ Historical entries accumulate fast. If your IC cycle goes live with wrong accounts, every transaction posts to the wrong GL accounts from day one. The longer it runs wrong, the larger the reclassification effort.

What We Automated and Why It Mattered

A client's intercompany order booking process was manual and painful. The Intercompany Specialist had to log into multiple EBS responsibilities, create a PO Requisition by hand, run "Create Internal Orders," then open the Order Import Corrections form just to fix the currency. From there, it was back into the Internal Sales Order to populate a dozen header and line fields, attach three document types, and trigger an eConfirmation. With 300 to 400 transactions per year at roughly 15-20 minutes each, that's over 100 hours of repetitive, error-prone work annually. We built an APEX automation to collapse most of these steps into a single APEX session.

Before vs. After: the 9 manual steps required to create and book a single intercompany sales order: now collapsed into 3 steps with APEX. And this is just Stage 1 of a typical 15-20 step intercompany flow.

ERP Features We Leveraged

The solution is built entirely on standard Oracle IC programs: Requisition Import, Create Internal Orders, and Order Import all run as designed. What we built on top was a PL/SQL orchestration layer that 1) populates the interface tables, 2) fires each concurrent program in its proper sequence, 3) waits for each to complete, 4) validates the output, and then moves to the next step. We stood up a single custom concurrent program, "XX Launch Intercompany Process," to control the end-to-end chain.

We came up with the concept of 'Intercompany Profiles' to capture setups by intercompany scenario - by customer, OU, Legal Entity (LE), and/or intercompany type. Each profile stores pre-defined values such as the OU, org, subinventory, price list, currency, shipping method, FOB, and freight terms so that each new transaction starts pre-configured for the user. Two Descriptive Flexfields on the Requisition Header and Lines capture the External SO traceability IDs throughout the end to end process.

"Set it once, and then reference it every time."

What APEX Contributed

EBS forms can't do what APEX does. The specialist has a single APEX webpage to navigate to and work with. They pick a profile, select the External Sales Order from a filtered list, and immediately, APEX displays populated fields for review before submission. For example, if there's a negative margin on the order, they can email for approval directly from the APEX app before submitting.

Once submitted, a progress tracker shows each concurrent program firing and completing in real time.

The log file, below, for the main controller Concurrent Program, 'Launch Intercompany Process' (shown above), includes details of each step taken during the Intercompany Automation Process. It also includes the Requisition Number and Internal Sales Order Number created by the process and status of uploaded attachments.

And keep in mind: everything above is just the booking stage. Fulfillment of both sales orders, warehouse receipts, IC AR and AP invoice generation, GL transfers, posting, and reconciliation all still lie ahead. Each can be a multi-step process of its own. This is how a single intercompany transaction can stretch to over 20 steps end-to-end.

Closing Thoughts

Everything above, the three intercompany types, the chain-of-dependency failures and the validation checklist - apply whether you're on R12 or Fusion. The specific configurations, tables and SLA behavior, vary by version and deserve their own treatment. But get the concepts right first. Then you can focus on the version-specific execution. Have fun!

As always, reach out and let me know how your intercompany design goes. I'd love to hear what you find. 🙏

Oracle's consignment solution, across EBS 11i, R12, and even Fusion Cloud, only covers the buy side. Here's how we designed a complete sell-side consignment process using standard EBS transactions.

If you've been looking for a way to handle sell-side consignment in Oracle EBS, where your company is the consignor placing samples at a customer's location, this post is for you. Oracle doesn't have a module for it. Not in 11.5.10, not in R12, and not fully in Fusion Cloud either.

This post documents how we designed and validated a complete sell-side consignment process using nothing but standard, out-of-the-box EBS transactions. I'm sharing it here because I couldn't find this solution documented anywhere when I needed it, and I suspect others are stuck on the same problem.

3 Key Takeaways ✍️

In case you are pressed for time, here are three key points I hope you take:

💡 Takeaway 1

Oracle's consignment module is buy-side only, across all versions. EBS 11.5.10, R12, and Fusion Cloud all provide consignment tracking for when your company is the consignee. None of them natively support the scenario where your company is the consignor.

💡 Takeaway 2

Separate billing from inventory movement. Bill Only Sales Orders handle invoicing (they don't touch inventory) and Account Alias Issues handle the inventory relief (they don't create invoices). When these two are combined in the right sequence, you get the benefits of both - without needing to pick, pack, or ship product that hasn't moved.

💡 Takeaway 3

Test with real numbers in a live instance. Our most surprising discovery, that the Account Alias must point to COGS, not back to the inventory account, only surfaced because we inspected GL entries line by line. The configuration may look correct but the results were wrong.

1. The Problem Statement

If you've ever searched Oracle's documentation for "consignment," you've found supplier-side (buy-side) consignment tracking. This is the scenario where your company is the consignee: a supplier parks inventory at your warehouse, and you pay for it only when you consume it. This is true in EBS (11.5.10, R12), and even Fusion Cloud.

But what if your company is the consignor? For example, you may manufacture inventory or samples for customer evaluation, ship them to a customer's location, and the customer sits on them for 10, 30, or 60 days before deciding to buy. Until they commit, the product stays on your books.

That's sell-side consignment. And no version of Oracle ERP has a native workflow for it (yet).

💡 What Is Consignment?

In a consignment arrangement, goods are physically transferred to the customer (the "consignee"), but title and ownership remain with the vendor (the "consignor") until the customer decides to purchase. Until that point, the inventory stays on the vendor's balance sheet.

Here's the scenario we faced: my client, a Canadian manufacturer, needed to place consignment samples with its French subsidiary's end customers across France. Canada needed to retain ownership until purchase, track inventory at each consigned location, and record the intercompany sale (Canada as supplier to the French entity) if and only when France's customer purchased.

2. The Business Pain Points

My client was shipping samples from Canada to its French entity using Oracle ERP's Intercompany Internal Requisition / Internal Sales Order (IR/ISO) workflow to move inventory between the two legal entities. Once a sample arrived in France, it was forwarded to the end customer for evaluation with no corresponding record in the ERP. Only if the customer decided to buy would the external sale be recorded. Here's what was going wrong:

Pain Point #1: Ownership Integrity

Intercompany orders (from CAN to FR) result in a shipment event, which trigger ownership transfer to the subsidiary. This contradicts the entire premise of consignment. Auditors would not be able to truly reconcile who owned what when.

Pain Point #2: Fake Logistics

If and when the customer decided to purchase, the external customer order process required pick, pack, and ship confirm for product that was already physically sitting at the customer's location. Warehouse operators were executing "phantom" shipping confirmations - generating move orders, packing slips, and Bill of Lading documents for items that moved weeks ago.

Pain Point #3: No Consignment Visibility

There was no way to see, at a glance, which samples were sitting at which customer's location, how long they'd been there, or what their total inventory value was. Samples disappeared into a black hole between shipment and purchase.

3. Approaches We Evaluated (and Why Most Failed)

We didn't arrive at the final design on day one. Over multiple tweaks and research, testing, and iteration, we evaluated six different approaches:

4. The Solution: The Consignment Sale Model

💡 Here's the insight we landed on: separate billing from inventory movement.

The design uses four standard EBS transaction types, combined in a specific sequence and zero code customization (except for generation of custom shipping documents to accompany samples during subinventory transfer "shipments").

Why This Works

Subinventory Transfers keep inventory on the consignor's books while tracking physical location. The Material account on each subinventory drives the GL, so a transfer from Finished Goods subinventory to a customer-specific consignment subinventory simply reclassifies the balance sheet. This is perfect for consignment - no P&L impact and no ownership change.

Bill Only Sales Orders create the invoice and recognize revenue without triggering any inventory transaction. In other words, a Bill Only SO does not touch inventory. It fires Dr: Receivable / Cr: Revenue only.

To support the external customer sale, Account Alias Issues relieve inventory from the consignment subinventory and record COGS. The GL fires Dr: COGS / Cr: Inventory.

By designing the Bill Only SO and Account Alias in the proper sequence, you get both the financial transaction and the inventory movement without ever needing to pick, pack, or ship anything.

For the intercompany sale between the corporation's legal entities (Canada to France), a Miscellaneous Receipt brings inventory onto the French's subsidiary's books at the intercompany transfer price, hitting an IC Clearing account that offsets the receivable at consolidation.

5. End-to-End Process Walk-through

Here's the complete flow for a sample that travels from the Canadian parent --> the French subsidiary --> the French customer's location, and is eventually purchased. I've included the GL entries at each step because getting the accounting right was our first priority.

Phase 1: Ship to Consignment

Phase 2: Customer Evaluates

Phase 3A: Customer Returns (No Sale)

Phase 3B: Customer Purchases

6. Consignment Model vs. Intercompany Process

Here's a side-by-side comparison. This table was key to getting stakeholder buy-in:

7. Subinventory Strategy: Per-Customer vs. Single Consignment Bucket

One design decision we spent time on: should you create a dedicated consignment subinventory for each customer, or use a single bucket for all consigned samples?

Here's why: with per-customer subinventories, each one gets its own Material account in the GL. That means the balance of consigned inventory at each customer is visible in your chart of accounts without any custom reporting. Oracle's standard on-hand reports work as-is: filter by subinventory and you see the customer. Partial returns stay traceable because product goes back to the customer-specific subinventory. And each subinventory maps naturally to a consignment agreement with that customer.

The single-bucket approach is simpler to set up (one subinventory for everyone), but you lose all native customer-level visibility. You'd need custom SQL joining MTL_MATERIAL_TRANSACTIONSand Sales Order tables to figure out which customer has which sample.

The setup overhead for per-customer subinventories is two steps: create the subinventory, assign a Material account, done. If your customer base is manageable (dozens, not thousands), the per-customer approach is the clear winner.

8. The Gotchas That Burned Us During Testing 🔥

These are hard-won lessons earned during testing. Each one of these caused real problems during our validation. I'm sharing them so you don't have to learn them the hard way.

1. Gotcha #1: Not Recognizing COGS

The Account Alias must point to the COGS account - not the consignment inventory account. If you point it back at the inventory account, the debit and credit net to zero. The inventory never leaves your books. COGS is never recognized. We caught this during testing when the GL entries balanced perfectly - which was the sign something was wrong. This is the kind of result you only catch by inspecting GL entries line by line. Be careful.

2. Gotcha #2: Bill Only SO Does NOT Relieve Inventory

This is by design (but misunderstood by many clients). If you book the Bill Only SO and forget to execute the Account Alias Issue, you'll have revenue on the P&L but the product will still be sitting in your consignment subinventory, indefinitely. COGS will be understated. Build an automated check (we use Oracle APEX to house the business logic and report errors) that flags any Bill Only invoice without a corresponding Account Alias Issue within a defined window.

3. Gotcha #3: Costing in your Subsidiary Organization

The Miscellaneous Receipt in the subsidiary organization requires an item cost for the item, even if the item is simply passing through the org. Without it, Oracle posts the receipt at $0, resulting with inventory on the books at zero cost. When the subsidiary sells it to the end customer, their margin looks like 100% - a major overstatement. To resolve this, define a cost for every sample item in your subsidiary as part of the item setup process, before any Misc Receipt is executed. In our case, we automated the setup of an item cost, again with Oracle APEX.

9. Advice for the ERP Community

Here's what I'd pass along if you're solving this same problem:

1. Start with the GL, not the transactions. We ranked our design priorities with GL integrity as first, EBS transaction flow as second and end-to-end walk-through, third. Getting the accounting right forced us to pick the right transaction types, not the other way around. If you start by asking "what EBS transactions are available?" you could end up with a workflow that creates technically valid but inaccurate accounting entries.

2. Test with real numbers in a live instance. Our Account Alias discovery (Gotcha #1) only surfaced because we ran a transaction and inspected the GL entries line by line. The configuration looked correct but the accounting was wrong. Whiteboard designs don't catch this so watch out for this.

3. Separate physical movement from ownership transfer. This is our fundamental principle. Product moves in the system when it moves in the real world (subinventory transfers). Ownership changes only when the customer says "I'll buy it" (Bill Only SO + Account Alias). If your design couples these two events (physical movement and ownership change), you don't have consignment - you'll just have a regular sale with delayed shipping.

4. Don't fight the ERP - configure it. Every transaction in our design is a standard, out-of-the-box EBS function: no custom workflows, no modified PL/SQL, and no form personalizations. We configured standard transactions in a specific sequence to produce a behavior Oracle ERP doesn't natively support. This proved to be the safest approach.

Conclusion

Sell-side consignment is a gap that spans Oracle EBS 11.5.10, R12, and even Fusion Cloud. But with a disciplined combination of subinventory transfers, Bill Only Sales Orders, Account Alias Issues, and Miscellaneous Receipts, executed in the right sequence, pointed at the right accounts, we were able to build a complete, auditable consignment process. The design principles apply regardless of which Oracle platform you're on. Good Luck!

A product recall is one of the most time-sensitive crises a manufacturing company can face. The ramifications ripple across every corner of the enterprise - procurement, inventory, production, sales, shipping, and your customer install base, all at once.

The challenge isn't just what to do. It's being able to see the full picture fast enough so you can act.

In this post, I'll walk through how we built a single-page dashboard that gives decision-makers an instant, enterprise-wide view of a recalled raw material's impact, so they can act in minutes, not days.

Problem Statement

When a raw material (RM) is flagged for recall or a quality issue surfaces, you need to quickly answer questions like:

• Which Bills of Materials (BOMs) reference this RM?

• Which Work Orders (WOs), Purchase Orders (POs), and Sales Orders (SOs) need to go on hold?

• What Finished Goods (FGs) are at risk. And do any have a substitute RM?

• What's already shipped and sitting at customer sites?

• What's in-transit or pending receipt?

The problem is that this data lives across every corner of your ERP, and it's tangled like a spider web. Tracing a single RM through open and closed orders, multiple BOM versions, serial numbers, and shipment records is overwhelming.

The Current Reality

Without a dedicated solution, here's the typical workflow in a recall situation:

1. Work with software developers to write SQL queries and export inventory data, PO status, sales history, shipment details, and customer reach.

2. Receive the exports, massage them in Excel

3. Only then can they extract the critical decision criteria and begin to act.

This process takes days. It involves sifting through multiple BOM versions and alternates, open and closed orders across modules, and a massive collection of interrelated data. And because of the time and resource drain on primary decisions (halt operations? notify customers?), there are no resources left for secondary analysis, e.g., understanding the full RM-to-FG impact, identifying all downstream ramifications, or exploring how to prevent this in the future.

Solution Overview

We delivered a one-pane-of-glass dashboard, a single-page APEX app that summarizes the full impact of a recalled raw material across the enterprise.

At the top of the page, key metrics are displayed as clickable badges - On-Hand Quantity, On-Hand in FGs, Shipments, Open Jobs, All Jobs, Open POs and All POs. Each badge is drillable. Click on any one and it takes you directly to the detail - the Work Orders, Purchase Orders, Sales Orders, Shipments or Inventory transactions behind that number. No more hunting across multiple ERP screens or waiting on a developer to pull the data for you.

With this one page summary, a decision-maker can quickly assess the lay of the land and execute: reach out to Sales to communicate customer impact and put WOs, SOs and POs on hold.

Screenshot of on-hand inventory drill down by subinventory for a RM, along with serial number lineage.

Screenshot of on-hand inventory drill down by subinventory for a Finished Good

Screenshot of Recent Shipment Lines Drill-Down

Finished Goods Impact Analysis

Scrolling down the page, the dashboard lists every Finished Good impacted by the recalled RM. For each FG, it highlights whether a substitute (alternate) raw material exists.

• Cells highlighted in red indicate the FG has less than three backup substitutes with enough on-hand inventory to replace the recalled component. This enables a quick decision: prioritize finding an alternate RM or put future orders for that FG on hold.

FG Workbench

From the one-page summary, clicking the FG Workbench button opens a detailed view of a specific Finished Good. Here you can see its real-time status at a glance - open Sales Orders, active Work Orders and on-hand inventory by subinventory.

But the real power is in the BOM drill-down. Click the RM BOM icon next to any FG and a pop-up displays all active BOMs for that Finished Good, along with the real-time on-hand quantities of each component per BOM such as how many units of the RM are on open Jobs and POs, as well as how many are in stock. You can also filter BOMs by status to narrow your view.

From here, if you want to deep-dive into a specific raw material, click the RM Workbench button.

Raw Materials Workbench

The RM Workbench provides a comprehensive, real-time view of the RM:

• Captures all transactions for the RM

• Identifies every FG made with the RM

• Flags any at-risk FGs if the RM were recalled

• Displays related and alternate RMs along with their current on-hand inventory and projected availability based on open demand

How do we identify substitute RMs? By leveraging the fact that multiple BOM versions often exist for the same FG, each referencing a different RM. By comparing BOM definitions, we can surface the substitute items without having to perform a manual search.

How We Built It

Building this solution came down to two things:

1. Mapping the business logic to the ERP data model

2. Reusing views and functions and leveraging APEX Collections for performance and maintainability

1. Mapped Business Logic to the ERP

Before writing a single line of SQL, we mapped out the full business algorithm. For a potential recalled RM, the business logic flows like this:

Lookback Period is a user-selected parameter (1, 2, or 5 years) that controls how far back the queries reach across WOs, SOs, PO receipts, and inventory transactions.

2. We Built for Reuse and Performance

We utilized three patterns to improve reusability and performance:

1. Database Views - complex queries were written once and referenced across multiple pages and reports. When a business rule changes, you only update it in one place. (For a deeper dive, check out Jon Dixon's post on the importance of using DB views in APEX.)

2. PL/SQL Functions - Instead of duplicating the same calculations and logic across multiple queries and views, we wrote the SQL once as a function and called it wherever needed.

3. APEX Collections - used to stage and share data across pages within a session, reducing need to re-run expensive queries on every page load.

Could AI Have Built This?

Honestly, not yet. And here's why.

The hard part of this solution wasn't writing the SQL. It was knowing which tables and columns to pull from in the first place. An Oracle ERP schema can have thousands of tables. Even seasoned developers spend significant time hunting for the right table - the one that actually populates the field you need, not just the one that has the field.

In one test case, we were tracking a serial number through the shipment tables. The table we initially queried had a serial number column, but it never populated. We could see the serial number in the ERP UI, so we knew it was captured somewhere. It just took several iterations to find the right table.

AI faces the same challenge. Without knowing which column from which table to reference, a generated query may look correct but return inaccurate results. The validation burden doesn't go away, it just shifts. You still need someone who understands the business scenarios, knows what "correct" looks like, and can test exhaustively to prove the solution right.

One more thought worth noting: the reason this solution works is because the underlying data exists to query in the first place. Years of consistently capturing transactions in the ERP (POs, WOs, SOs, shipments, serial numbers, etc.), built the data foundation that makes real-time decision-making possible.

As Accenture CEO Julie Sweet noted recently:

“over 90% of data clean-up that companies have, when you look across the globe, is still to come.” Julie Sweet, Accenture CEO, Jan 20, 2026.

The companies investing in their data foundation today are the ones who will be able to act fast when it matters most. Do not be part of this 90%.

Conclusion

The queries are straightforward. What's hard, and what I hope you took away from this post, is knowing which tables in the ERP database hold the data you need, and that knowledge only comes from experience and exhaustive, iterative testing. Even our developer, with 30+ years of Oracle ERP expertise, had to try multiple tables before finding ones that actually returned the serial numbers and transaction details the business needed.

What used to take days of manual SQL exports, Excel manipulation and cross-referencing now takes minutes on a single APEX dashboard. Decision-makers can assess the full impact of a recalled raw material across Procurement, Inventory, Production, Sales, Shipping and their Customer Install Base.

If your enterprise handles raw materials, components or any product with a supply chain, I hope I have inspired you to build a similar impact analysis application.

As always, reach out and let me know how it goes. I'd love to hear about your use case and help.

3 Key Takeaways ✍️

In case you are pressed for time, here’s how I approach designing APEX apps for longevity:

1. Start with a Robust Data Model

2. Leverage Database Views

3. Build Configurability into Key Variables

Use Case

In a previous blog I described the situation where my client, with over 600 legacy systems in place, was launching an ERP transformation project. We needed an artifact to capture our analysis of how the new ERP would impact each system -would the legacy app now be replaced, retired, updated or upgraded?

Most consulting companies, including the Big 4, use spreadsheets to capture their analysis, and our team did the same.

Please Say ⛔ To Spreadsheets for any System of Record Work

Quickly, we ran into the issues described in Key Takeaway Point # 2 of my previous blog on building a Systems Assessment Application. No worries - Oracle APEX to the rescue. In less than 5 minutes, I built an APEX app based on the project’s spreadsheet implementing the Speedy Approach below. The team crowned me hero for the day 👑.

Then, came the request for additional features. Oh, I wished I had taken the more Scalable approach, described further below.

The Speedy Approach

This is a perfect path for one-time use cases. Simply allow APEX to convert your Excel sheet to a web app (here's how).

Within four minutes, APEX created four pages automatically for me:

1. Home Page

2. Dashboard - displays key metrics and trends at a glance

3. SysAssessment Search - to filter and search to my heart’s content

4. SysAssessment Report - an Excel-like report view which allows me to create new and edit existing records.

Home Page is illustrated below. Refer to my previous blog to view additional pages from the app.

☝🏼Quick Tip

☝🏼Quick Tip

A More Future-Proof Approach

It’s rare for an APEX app to remain static, particularly in the enterprise. As soon as usage grows, users start asking for new features and enhancements. That’s why an app needs to be designed to evolve.

Over time, I’ve learned to build every app with three foundational pillars that make it more future-ready and adaptable. Here’s how I approach designing APEX apps for longevity:

1. Start with a Robust Data Model

2. Leverage Database Views

3. Build Configurability into Key Variables

1. Start with a Robust Data Model

Do not model data until you can answer “I know what each record represents.” Model why the data is being collected, not just what. For my use case (the systems assessment app above), the why is clear:

from my previous blog’s conclusion: a system assessment reveals the changes that need to be made in your environment to make the most out of the new ERP. It produces a Decision Matrix highlighting the systems that need to be upgraded, retired or replaced and applications that need to remain to fill gaps the ERP cannot address.

Next, think through what data elements to segment the application by. I knew I wanted to partition by:

1. Client - as a consultant, I want the flexibility to reuse this application across multiple clients; multi-tenancy to allow to filter by customer or lines of business within a client

2. Event - I want the ability to run multiple assessments at the same client site, not just one, e.g., 2024 Assessment, TEST, Simulation v1, Simulation v2, etc.

With these two in mind, here’s my 2-minute data model:

After creating my own ERD, I thought I would ask AI to give it a try. See my attempts below with both GPT-5.1 and Claude’s 4.5.

👇🏼 🤖Here’s GPT-5.1’s 2-minute data model:

👇🔥And… here’s Claude’s 2-minute data model:

This is the prompt I used for both AI systems:

You are a data model design expert for Oracle APEX enterprise applications. Review the attached spreadsheet showing a systems assessment—a company exercise that produces a Decision Matrix for legacy IT systems before the start of an ERP implementation.

A systems assessment evaluates legacy applications across three dimensions:

1. ERP Compatibility: Redundancy analysis, integration capabilities, data touchpoints

2. Risk Assessment: Compliance, security, vendor support status

3. Sustainability: Integration-readiness, scalability, total cost of ownership

Deliverables:

1. A multi-tenant data model in Mermaid ERD syntax

2. SQL DDL scripts for Oracle APEX

3. Sample CSV data (3 clients, 2 assessment events each, 450 systems per event)

The data model should support these goals:

1. Support multiple clients, each with multiple assessment events.

2. Each client is a tenant. Tenants cannot see each other’s data.

3. Allow clients to create, rename or retire assessment criteria without schema changes.

4. Allow dynamic rating scales (e.g., Yes/No, 1–5, 0/0.25/0.5/1) by criteria.

5. Track every rating, including rater, rating value, scale version, timestamp, and comments.

6. Maintain full lineage and auditability.

7. Allow reporting across events, clients, and systems.

8. Create and maintain multiple events of a systems assessment by client.

A couple of observations:

• Each AI system produced a more comprehensive data model in two minutes than I ever could.

• Each data model solves for the relationships between the rating scales, values, ratings and weights. Again, this is something that would have taken me numerous iterations to solve.

So, where could this go wrong?

Solely relying on AI-generated data models can be risky because they don’t understand your business context, infrastructure or edge cases. They may design poor indexes, over-normalized tables and not account for performance. Worse, I’ve seen AI miss critical security considerations, like allowing client’s to see each other’s data.

Bottom line: Treat the AI-generated data model as a high-quality first draft. Know that it will require a high level of validation and iteration to finalize. Only you and your domain experts can validate whether it is a true fit for your environment.

NOTE: It took eight iterations to arrive at my final prompt. With the release of GPT-5.1 and its new 5.1 Prompting Guide, which emphasizes that this latest version follows instructions more literally, it’s essential that prompts do not contain any conflicting instructions, else, the AI will try to resolve them.

Mitigating data model risks

Here’s what I do to validate my application’s data model:

1. Go deep on the requirements. Drill down two to three levels deep on each one. Challenge every requirement: Does it always apply? What about in x situation? What business conditions could make it obsolete?

2. Capture real use cases. Include high-risk and exception scenarios. I test every business rule against edge cases like nulls, duplicates and boundary conditions.

3. Performance test. Load test with high volume and concurrent users.

4. Multi-Tenant Isolation. Verify tenants cannot access each other’s data.

5. Have a DBA review the schema. For example, my project’s DBA warned that the criteria / ratings design suggested by the two AI systems above, will likely not scale to thousands of systems. He recommended materialized views or de-normalization for better performance.

Validation is grueling work. Your years of experience have built an intuition for spotting errors. Your client is paying exactly for this expertise. Push yourself hard here. It pays dividends in time and rework saved down the road.

2. Leverage Database Views

Different APEX pages and reports interact with the data in your app in different ways. Instead of writing a complex query in every APEX page, you create a view once and then just reference it where needed. The view handles all the complexity behind the scenes. For example,

• Maintain less code - With a view, you can write complex calculations and combine data from multiple tables once - then reference the view multiple times across your app. When a business requirement changes, make the change in the view rather than having to make the same update in 20 different pages.

• Store business / security rules in one place - Instead of repeating the same filters and access rules on every APEX page, build them once into your view. All pages automatically enforce the rules, and when you need to update the security, you only have to change it in one place.

• Compute-On-The-Fly - You can introduce creative logic in a view so you do not have to add physical columns to your tables. Build the logic once, apply everywhere. This also helps keep your base tables clean and normalized.

3. Build Configurability into Key Variables

Instead of hard-coding variables, turn them into Lookup tables so they can be updated without having to update code.

For example, the screenshot below shows how variables that would typically be hard-coded were converted into Lookups for a Document Generator solution. The URLs, object store bucket names and file paths are now configurable. If the client wants to change the object store bucket the Document Generator uses, they simply update the Lookup value - no code change required.

Conclusion

Building scalable Oracle APEX apps requires moving beyond the quick “spreadsheet-to-app” conversions. Investing the time upfront in designing a well-validated data model, using views to centralize security and business logic and storing key variables in lookup tables instead of hard-coding them, you enable your applications to scale and adapt as your business evolves. Your future self will thank you :)

A systems assessment exposes what changes need to be made to get the most out of your new ERP. It highlights what existing systems can now be replaced or retired and which need to remain to fill gaps the ERP cannot address.

This effort is often underestimated. Consider the following:

A 2025 survey by MuleSoft revealed that companies use an average of over 900 applications across the enterprise.

This figure includes homegrown, commercial-off-the-shelf (COTS), Mainframe, .NET, On-Prem, Cloud and SaaS applications and interfaces. Although the survey only included large companies with over 1000 employees, it’s still a staggering number.

But it’s not far-fetched. Here’s a real world example.

A recent client with over 600 systems in place, was comparing SAP versus Oracle Fusion ERP. As part of the evaluation, we analyzed how each ERP would impact the system landscape. The ecosystem was full of duplicity. For example, the company had eight distinct, siloed ERPs, one for each line of business. Each ERP performed similar functions, resulting in an eight-fold increase in integrations, licensing costs, and maintenance.

Additionally, 20% of systems were homegrown or on a Mainframe stack. Other systems, acquired through past mergers, were not well understood or considered too fragile to move or automate, impeding the company’s ability to scale and support new capabilities. The application landscape became too large to manage efficiently.

I highlight my client’s experience to show that a systems assessment not only determines what systems are impacted by the new ERP, but also exposes the overall health of your ecosystem. In total, it can deliver:

1. ERP Compatibility Assessment - identifies redundant systems or those with overlapping functions to the new ERP. If a system cannot be replaced by the ERP, can it integrate with it, and if so, what are the master data and transaction touch-points?

2. Risk Assessment - evaluates the health of a system, e.g., is it up-to-date, regulation-compliant, secure and supported?

3. Sustainability Assessment - evaluates the system’s test of time, e.g., is it integration-ready, configurable, maintainable, performant, scalable, affordable?

A systems assessment will produce an actionable Decision Matrix of what systems needs to be integrated, retired or replaced.

3 Key Takeaways ✍️

In case you are pressed for time, here are three key points I hope you walk away with:

These tools will miss:

1. Work performed in Spreadsheets - all downloaded and manually-tracked spreadsheets used to perform work.

2. Work performed by Human APIs - manual data entry between systems. Not all systems are integrated. Per the MuleSoft survey above, only 28% of systems are integrated, across large enterprises.

There are too many pitfalls when tracking entries and changes across hundreds of columns and rows. Which one of us has not experienced:

• “Who has the latest version?”; “Can you please check it back in?”

• File corruption or loss of data.

• Duplicate versions after someone forgets to check in their edits.

• Not everyone is familiar with VLOOKUPs and can accidentally break them

• Typos, leading to inaccurate conclusions. Did you know that manually-typed data has a 2-5% error rate?

Instead, Use Oracle APEX or another low code tool to track and maintain this crucial artifact. 👉👉 NOTE: this post is long so I wrote another post illustrating how I used Oracle APEX to create a systems assessment app here.

Yes, it’s hard to start, hard to complete and time-intensive. It requires access to people who understand the dependencies and complexities of each system and demands meticulous documentation.

Many companies get stuck in analysis paralysis, while others don’t know where or how to start. Perfection is the enemy here - even an 80% completion rate is a huge win given the limited information available to most teams.

Start with a small subset of systems and a few parameters (see the Criteria section below for a sample list).

How We End Up With So Many Systems

How do companies end up with hundreds of systems? Here’s a list of all the reasons I’ve collected over the years:

1. Mergers and acquisitions play a big part, where systems from newly-absorbed companies are not integrated into the existing ecosystem.

2. New systems are introduced because existing ones cannot accommodate the needs of a new line of business

3. “We’re stuck on an old version because upgrading customizations is costly and disruptive.”

4. Technical debt. Typically, when a company transitions to a new system, the old legacy system is kept running.

   👉 Here’s why:

   1. Other legacy systems rely on the marked-for-retirement system. Either the legacy systems do not have the capability to integrate with new systems or it's not worth the cost or risk to integrate, so the marked-for-retirement system remains.

   2. Mainframe and custom code apps. Often, no one left knows how these systems work. The adage, “if it’s not broken, do not touch it”, applies here.

   3. And the most frequent cited reason: "We've relied on it for so long, what if we need it for something? Let's just wait a bit longer and we'll retire it in a few months".

      Those few months turn into years. A new team comes in and has no idea what that system was ever used for, but again, afraid to touch it, so it remains in perpetuity.

What You Can Expect From An Assessment

An assessment exercise is one of those where you will get out what you put in. When complete, your assessment can deliver:

1. a complete, up-to-date view of the company’s current tech assets

2. An unbiased assessment (a Decision Matrix) of what apps need to be upgraded, integrated, replaced, consolidated or retired

   1. A listing of what can and should be replaced by the ERP

   2. A listing of what needs to integrate with the ERP

   3. A listing of systems that pose the highest risk to your ecosystem

3. With this Decision Matrix in place, you can:

   1. design a multi-phase roadmap, outlining which systems to tackle first

   2. estimate total implementation, integration, decommissioning, licensing and maintenance costs

   3. estimate total cost savings due to a reduced footprint (lower licensing and capital and operating expenses due to less legacy upkeep)

4. Finally, the executive team will be interested in aggregated summaries, analyses and recommendations including:

   1. A risk assessment analysis - systems that pose the highest risk to your ecosystem, with mitigation recommendations

   2. A technical debt analysis - a listing of technical debt that poses the highest impact to your program, with recommendations on how to mitigate and manage.

   3. Summary of Findings - key observations from engineer and support team interviews, such as:

      1. “We have a dependency on key resources for technology or architecture skills:

      2. “We lack process and standards relating to patch levels”

      3. “We lack password and access management - some admin passwords are still ‘password’, shared with many employees and contractors and never been changed.”

      4. “Backups and DR never attempted or successfully tested for over 40% systems”

      5. “We lack a robust Helpdesk ticketing system; have over 65% open and unresolved tickets.”

   4. Recommendations & Mitigations - represents mitigations to findings above, such as:

      1. “Establish Privileged Access Management. Enforce password updates every 90 days, enable multi-factor authentication for critical systems.”

      2. “Formalize a Disaster Recovery Program. Establish testing plan by system priority.”

👉 Armed with these insights, the next step is to understand how the ERP and system assessments connect - and why one should come before the other.

An Essential Prerequisite

Here’s why: you have to understand what you need and why - that’s the purpose of the ERP assessment. It maps your business processes and requirements against what the ERP can and cannot do.

With the ERP assessment in place, you can move on to the systems assessment to evaluate which systems can truly be retired versus which ones need to remain. Those that need to remain are kept because:

1. they fill gaps the ERP cannot address or,

2. another essential system depends on them

• To expand on point 2 - If the ERP assessment recommends replacing all eight existing legacy ERPs, the system assessment verifies whether this is feasible. For example, if one essential legacy system, outside the ERP project scope, depends on two of the eight ERPs, those ERPs cannot be retired until the dependency is resolved.

💰💰💰This is why system assessments pay off. It is best to identify dependencies ASAP so that integration, licensing and other costs are known in the beginning of the program.

How To Begin 🛠

1. Take inventory of all systems. Include not just applications but also spreadsheets used for business work, interfaces, APIs, and human-API activities.

2. Determine how you will assess each system. Consider criteria such as security, compliance, scalability, reliability and performance. I’ve provided a tabular list of the most common criteria below 👇

3. Apply weight factors. Weighting helps reflect relative importance. For example, if ‘HIPAA compliant” is three times more important as “IPv6 readiness”, a simple ranked list doesn't convey this importance, but a weighted list (e.g., HIPAA = 6, IPv6 = 2) does.

4. Rate each system. Assessments are a team effort. You can divide up the effort by:

   1. Expertise: security teams assess security criteria, operations teams assess reliability and performance, etc.

   2. Comprehensive Review: Every team member rates all systems, then discusses variances. This second approach takes longer but can bring about the most information and learning.

5. Analyze, summarize and present. With each system rated, your tool of choice can help you analyze, summarize and present the results. My tool of choice is Oracle APEX, as illustrated on the screenshots below. I’ve provided a screenshot of a spreadsheet for comparison purposes.

Spreadsheet version of the app above.

You can see I have categorized my 20 parameters by ERP compatibility, risk and sustainability considerations.

The filters above and the charts below auto-generated by the Oracle APEX tool when I uploaded my spreadsheet to the APEX tool:

For the purpose of this exercise, I used the following ratings for each assessment:

• ERP Map & Gap Assessment

  • Duplicate - system’s functionality can be replaced by the new ERP

  • Obsolete - functionality no longer relevant

  • Fills Gap - functionality the ERP does not cover

• Final Disposition Assessment

  • Retire - duplicate, high-risk, or obsolete; dependencies cleared.

  • Retain- fills a gap and poses low security risk

  • Upgrade - fills a gap but poses high security risk or low sustainability. Recommend to upgrade or replace.

Finally, Oracle APEX automatically provides me the ability to create new and edit my existing records as my assessment evolves:

Once your process is set, the next step is to agree on what you’ll measure — the assessment criteria.

Assessment Criteria

An important task as a team is to finalize the guiding principles to perform the assessment. Below is a listing of the most common parameters to evaluate systems. Not all are relevant to your enterprise so prioritize accordingly:

Once your criteria are finalized, you can begin scoring each system to reveal where modernization and/or retirement efforts will yield the biggest impact.

Conclusion

In summary, a global system assessment reveals the changes that need to be made in your environment to make the most out of the new ERP. It produces a Decision Matrix highlighting the systems that need to be upgraded, retired or replaced and applications that need to remain to fill gaps the ERP cannot address.

With this list of what systems need to stay or go, you can then estimate your integration, consolidation, decommissioning, licensing and maintenance costs for your ERP project and produce a multi-phase roadmap of which systems to tackle first.

The effort is significant but you only have to do the bulk entry of it once if you use a low-code tool like Oracle APEX to maintain a dynamic, continuously updated system inventory.

Every great ERP transformation starts with clarity. Your systems assessment is that first step. Good luck, and enjoy the discovery process! As always, reach out and let me know how it goes.

As an ERP consultant, I frequently need to troubleshoot why something is not working in the ERP or other enterprise system.

Many times, I need access to a system's setups or I need to compare settings between objects or environments. Instead of having to take screenshots across multiple pages or environments, I use my low-code development tool, Oracle APEX, to quickly gather all the data in one place.

Take this recent example where I was guiding my client through an ERP upgrade from Oracle EBS (E-Business Suite) to Oracle Fusion Cloud. My client had 40+ Item Templates and needed guidance on how to best consolidate the 40+ templates to an essential few. When you realize that each template contains 300+ attributes, you are comparing a matrix with over 12,000 values. A typical ERP form is unable to display all 300+ attributes in one page, so it forces you to scroll down 18-20 times to get to the last attribute, per template.

Scrolling through the hundreds of attributes in Oracle Cloud Fusion

Scrolling through the hundreds of attributes in Oracle EBS

There is a better way.

Better Ways To See Your Data

As you can see from the GIFs above, I need a more effective way to display and analyze my 12,000+ data points. Here is my workflow to quickly transform my data:

1. Extract data from the enterprise system

2. Download the data to Excel or csv

3. Upload file to Oracle APEX

4. Explore and analyze in APEX

Extract data from the enterprise system

I leverage SQL Developer for querying Oracle EBS records and BI Publisher for querying from Oracle Fusion. I find these tools offer the most efficient way of extracting setups and other necessary data from either ERP system.

My Data using the BI Publisher Tool in Oracle Fusion

My Data using SQL Developer for Oracle EBS

As you can see, these formats do not offer an optimal way of studying my data points.

Download data to Excel

Excel is a close second when it comes to analyzing data. I can filter, pivot and transform data to my heart's delight.

Upload Data to Oracle APEX

But look how much easier and funner (is this a word?) APEX makes this task for me. End users find this format simpler and more pleasant to work with. Compare the following two GIFs with the first two on this post - no comparison really.

This app took me two minutes to create, with just the upload of my file (here's how).

Notice the Faceted Search feature displayed on the left hand side of the page. APEX automatically detects the 'categories' in my file and builds the feature for me. The Search box feature is also automatically built-in, as displayed below.

This post on Faceted Search by Monica, from the APEX Development team, shows how APEX automatically builds dashboards and charts for each of your facets too.

These UIs makes a powerful statement when you're presenting in a meeting. The client loved this view of their setups so much they asked us to make it a permanent, real-time page in their Production environment. To transform this to a long-term solution, we built an integration to integrate the template data in ERP with APEX. This allowed us to provide additional features such as 1) dynamically adding templates when new ones were created in the ERP and 2) allow users to filter by template. See below.

Consequently, we ended up transforming other settings, setups, and similar pages to APEX as well.

Introduce APEX for one task, and you'll be asked to apply it everywhere in the company :)

And...

Explore & Analyze with Oracle APEX + Other Tools

APEX is a terrific starting point for visualization and analysis of large amounts of data. I complement it with advanced SQL queries to compare data across columns and identify patterns.

As a fun exercise, I uploaded my file up to ChatGPT to see if it could find similarities across templates. Here's what it returned:

And...

These pointers from ChatGPT are excellent starting points for any analysis. In order to consolidate the templates from 40 to a few, however, requires in-depth understanding of the dependencies AND inter-dependencies between the 300 attributes as well as their impact to other setups across the ERP. Mapping the features and functions of these attributes with the ultimately business goals of the client, is what allows me to eventually narrow down the number from 40 to five. AI can't do this for us...yet.

Summary

Transforming settings, setups and similar pages are one of my favorite use cases for using Oracle APEX to simplify the view of data. With APEX's easy file upload, I can transform any file into a modern, UI-friendly web page in just seven steps and under two minutes. And its automatic faceted search capability accelerates my data analysis because I can focus on identifying patterns, similarities, and variances in my data instead of building and coding an app.

I hope this post encourages you to use Oracle APEX to debug and troubleshoot your next issue. It makes me look good in front of clients, every time. :).

Here's what I'll cover:

1. Why is Order To Cash so hard?

2. My customer's problem statement

3. Oracle APEX to the rescue

4. Approach and design principles

5. Tools and Integrations

6. Results

Why is Order To Cash so hard?

Order To Cash, typically abbreviated as OTC or O2C, spans multiple functions including sales, credit, demand planning, inventory, warehousing, shipping, finance, collections and customer support. The numerous hand-offs, dependencies and exceptions situated across departments make automation and efficiencies difficult to achieve. And the more product lines, revenue models and fulfillment channels introduced, the more moving parts are put in motion, further compounding the problem of reaching cross-functional alignment and efficiencies.

Per a recent Boston Consulting Group article,

"Our analysis of O2C in a sample of manufacturing and service companies found that it comprised as many as 27 sub-processes across seven different functions. That’s why O2C often falls between the cracks or is regarded as being too complicated to re-engineer."

No two companies perform O2C in the same way, making it almost impossible for ERPs and other systems to provide standardized offerings.

"In the two decades I have spent leading O2C ERP transformation programs at companies, all have used ERPs to automate the backend financial processes. And, all of them relied on custom applications and manual processes when it came to order-to-cash.” - Nishant Nair, CEO of RecVue (Forbes article)

This variability across companies and industries presents an optimal opportunity for a low-code development platform such as Oracle Application Express (APEX) to meet a company's O2C needs. APEX offers the flexibility to build only the features you need today, with the malleability to enhance and adapt them for the future.

My Customer's Problem Statement

My client needed the ability to fast-track the order to cash operations for a company they had just acquired.

The acquired company objected to using an ERP to run its operations because it perceived ERP as too slow and complex and required too many windows and clicks. They believed an ERP could not compete in speed, performance, or efficiency with the QuickBooks solution they had configured to meet their exact needs.

So we were tasked with moving them away from QuickBooks to a solution that would not only meet the acquired company's expectations of speed and ease of use, but also seamlessly integrate with the existing ERP, ensuring a smooth and efficient transition.

The reluctance to move away from what they had in place today was so strong, I had to gamify the situation with a challenge. I proposed to the head of the acquired company that if the demo of our solution did not beat their current system in speed, performance and enhanced features, they didn't have to move. "Game on!", he proclaimed. The challenge was on!

Oracle APEX to the rescue

The initial aim was to deliver a solution entirely within Oracle ERP. However, if the solution proved unfeasible, our backup plan was to construct a custom web app with integrations to the parent company’s Oracle ERP.

They were right—ERP was slow and drawn out. Compared to their existing solution, it required many more forms, fields, pop-ups, and clicks to operate O2C end-to-end, and it took three times as long. ERP was a no-sell. A custom app was going to be the best route forward.

Good news—Oracle APEX is quick for standing up an application. Within a week, we had a working demo. Oracle APEX to the rescue!

Approach and Design Principles

An important design principle for custom enterprise apps is to design the custom app in lock-step with EBS the entire way. We referenced customers, suppliers, and items from the ERP and took advantage of standard ERP APIs to decrement inventory and generate invoices.

Table 1: Data Objects & Transactions Leveraged in the ERP

All these links minimized duplicity and ensured Oracle ERP remained the source of truth for master data and transactions.

Note - there is more to an ERP than just data and transactions. One of the primary reasons to have an ERP is to take advantage of its business rules and recommendation engines. These engines are powerful - they automate decision-making and enforce policies and procedures. We synced APEX with three key Oracle ERP robust engines:

Table 2: ERP Business Rule & Recommendation Engines

Having said all the above, it does not always make sense to originate all objects from the ERP. Our design tenets guide us to prioritize the user experience, simplicity, and longevity of the APEX apps we build. Thus, we created and maintained sales orders, pricing rules, work orders, and shipments, fully confined within the low-code app.

Table 3: Entities and Transactions Unique to APEX

Designing in lock-step with ERP can also mean complementing the ERP in a modular approach. As the list above shows, we built these four "modules" to house the transactions completely outside the ERP. The flexibility of our APEX platform allows us to amend or replace these 'modules' as future requirements dictate.

As mentioned earlier, a second design principle is designing for longevity. It's essential to avoid hard-coding whenever possible. Instead, consider storing variables in ERP constructs like ERP profile options and lookups or opt for the creation of custom tables managed by APEX pages. This approach avoids the pitfalls of hard coding and allows business users to update the variables themselves instead of relying on a code update.

There are many other design principles for building enterprise apps, but I'll end with a third one: optimizing the user experience. To optimize the UI experience, we designed the most frequently used functions to be accessible from one place—an OTC workbench. It provided buttons for saving, booking, generating a work order, printing paperwork, shipping, and invoicing all on one page. No more having to go to multiple pages to perform or access a function.

Every potential click was evaluated and optimized. We utilized defaulting-rule logic wherever possible and placed the fields in the exact sequence they needed. we ensured users never had to lift their hand to move a mouse; every section and button could be activated with keyboard clicks, eliminating steps and clicks along the way.

One key win was automating seven procedures, all with the click of one button. We called it “Rocket Ship”. See table below for the seven procedures it automates for end users.

Table 4: Procedures the Rocket Ship automates for end users

Tools & Integrations Used

No enterprise app worth its weight stands alone. Here's a list of key integrations we built:

Table 5: Integrations with our low-code APEX application

Integration between APEX and Oracle ERP is easy. If you're on an Oracle ERP EBS version, both APEX and ERP are in the same database, so it’s as simple as a SQL query or PL/SQL call to the specific table and column in the database - no API or Web Service configuration required. If you're on Oracle Fusion Cloud ERP, it's hosted by Oracle, so you'll need to stand up another Oracle database to host APEX. For examples of where to host, see Oracle APEX Service or the Autonomous Database Service on OCI.

Results

It took two of us (me and a developer) less than six months, start to finish, to gather requirements, prototype, design, build, iterate, iterate, and iterate and then launch to Production. This included full integration of the app's inventory and revenue transactions with Oracle Financials. The build was the easy part. The bulk of the time was spent educating my client on the features of ERP they could now take advantage of and redrawing their business process for optimal efficiency.

Automation and optimization of the user experience reduced order processing overhead by 80% compared to their legacy Quickbooks application.

And the 'Rocket Ship' button enabled no-touch order processing for 30% of orders. That's over seven clicks per order. if you extrapolate that over all its plants, that’s a savings of over 1/2 million clicks per year. Not to mention the context- switching each user saves - users only have to attend to an order once.

APEX came out ahead of Quickbooks in terms of speed, scale, performance, accuracy and enhanced features to their legacy system.

Summary

OTC is universal. Every company that sells a product or service engages in O2C operations, and each company's O2C workflows are unique. The variables, hand-offs, and exceptions involved in O2C demand a tailored solution for most.

The flexibility, security, and performance provided by Oracle APEX and its pre-built integrations with Oracle ERPs allow you to make the most of your ERP investment.

This post could have easily been 10,000 words—there is so much I didn't get to cover when enhancing an ERP with an app that spans multiple departments and processes. Optimizing ERPs is my passion—reach out if you'd like more information regarding this use case or if you'd like to bounce ideas about how this could work in your environment.

1. eliminated customer duplicates with the introduction of an "approximate string matching" algorithm

2. simplified the customer-creation process by reducing the number of forms and clicks required by over 65% with the introduction of an Oracle APEX web app

The Problem Statement

A client ended up with many duplicate customer records, so many that they were running the Oracle ERP Customer Merge program every quarter. In merger and acquisition environments, it is common for the acquirer and acquired companies to share the same vendors and customers. This was certainly the case with a client. But how does the ERP, the source of record, end up with duplicate customers? Here's how:

1. Oracle EBS does not enforce uniqueness in the customer name. For example, users were able to create "Cannon Industries" twice, each with a different customer account number:

2. It also does not auto-enforce naming standards. For example, “Golfsmith Inc” versus "Golfsmith Inc.“ with a period versus "Golfsmith Incorporated" can all be created. In the screenshot below, the three entries below for "Southeastern Metal Products" represent the same customer and address, but to the ERP system, they represent three distinct customers:

3. The Oracle Customer form does provide the ability to search for a customer. However, it is optional, meaning the user can bypass the search and proceed directly to creating a duplicate customer without any alert or notification.

4. Even if the user were to perform a search, the search is not effective. For instance:

   • "Golfsmyth" with a "y" does not return existing customer “Golfsmith” with an "i"

   • "Golfsmith Inc" would not return existing customer "Golfsmith Incorporated" unless the user knew or remembered to search with a % wildcard operator after the word "Inc".

Notice the customer entries for "All Metals Fabricating" below. When creating a sales order, which one should an end user choose? Randomly choosing one over the other will split the customer revenue across the two records.

5. Sitting down with end users revealed another obstacle. Users indicated the Customer form is overwhelming. They claimed that "editing a customer involves many nested tables and it’s easy to get lost. It feels safer to create a new customer than to edit an existing one".

Note the screenshot below - the customer "National Switchgear" has four active customer accounts in the ERP. Which one should the end user choose to transact with or update?

Conclusion: the complexity of the existing Customers Form and the shortcomings of the search feature to identify exact and near-duplicates all contributed to bloated Customer Masters across many clients.

The Approach

Addressing the five root causes above required a two-prong approach:

1. identify and display exact and near duplicates to the end user

2. simplify the view, edit and customer creation process in the existing Customer Master forms to address the fear and reluctance experienced by end users

Fuzzy Match

Oracle ERP documentation and Oracle Support websites offer methods to resolve duplicates, not prevent them, so we needed to think outside the box.

Note: Oracle EBS may offer near-duplicate search functionality with the license, use and configuration of the Data Quality Management and/or Customer Data Hub modules. These modules are not common; thus, this solution is applicable and popular with many Oracle EBS customers.

Oracle Cloud ERP also offers near-duplicate search functionality for customer search, but it may require additional licensing and tools such as Enterprise Data Quality, etc.

An Oracle search to resolve data duplicates lands on a blog by Richard Williams describing three helpful algorithms supported by the Oracle DB:

A Stack Overflow Page also describes “duplicate records that are similar but aren’t exact matches”.

They both describe a Jaro-Winkler algorithm, which was developed by the US Census Department. The algorithm returns a matching score when performing a search between 0 and 100: 0 meaning no match, and 100 meaning a perfect match. It is considered a "Fuzzy search" algorithm because it finds patterns in strings (approximate string matching) for entries that are approximately similar but are not precisely the same - Bingo for our use case!

The Jaro-Winkler algorithm is implemented as a PL/SQL function in the Oracle Database:

UTL_MATCH.JARO_WINKLER_SIMILARITY (
   s1  IN  VARCHAR2, 
   s2  IN  VARCHAR2) 
 RETURN PLS_INTEGER;

Running the function in our Oracle APEX test environment resulted in the following match scores when entering "GOLFSMITH" as a potential customer:

• match score of 88% when compared to "Golfsmith Incorporated"

• match score of 90% when compared to "Golfsmyth Inc." with a "Y"

• match score of 92% when compared to "Golf Smith", spelled out as two words

• and of course, a match score of 100% when compared to existing customer "Golfsmith"

See results in screenshot below:

This approach elegantly addresses exact as well as near-duplicate conditions. It highlights instances of misspelled words, abbreviations, punctuation, etc. - something very hard to do with our customers' current functionality.

Here's a snippet of the exact code deployed to get the results above:

Here are a few things to call out:

• Line 10: Here is where I call out the algorithm and assign it a column name of "MATCH_SCORE". UPPER function transforms both fields, the entered value and the value in the customer name column to uppercase to eliminate any potential case sensitivity.

• Line 20 - 24: I wanted match score results greater than 75 to be highlighted in blue, and thus, created a "HIGH_MATCH" function to do just that. The immediate screenshot below shows the CSS that turns match scores over 75 to blue. The CSS is captured in the Page section of the APEX web form.

• Line 26: This line restricts results to display only those with a match score >= 65.

Simplifying the Customer Create Form

We concluded that replacing the multi-nested Oracle Customer forms with a one-page Oracle APEX web app would be safer and simpler. Here's how we went about it:

• we gathered data and feedback from end users from multiple sites

• we sat with users to observe each keyboard click, decision, pause and hesitation

• we recorded user screens to further study every click, response and movement

This trove of data allowed us to design the APEX web app in such a way that:

• every field was placed in the exact sequence needed.

• every section, field and button could be activated with a keyboard click. Users would never have to lift their hand to move a mouse.

• every potential click was evaluated and optimized. We used Dynamic Actions in Oracle APEX to control the tab order between fields.

In all, we optimized the customer creation page to just 10 essential fields. We replaced the multi-page, multi-nested, 60+ fields on the Oracle ERP Customers forms with a lightweight, fit-for-purpose Oracle APEX web page.

There are two additional design principles we incorporated:

1. Design the Oracle APEX web apps in lock-step with EBS.

Using Oracle APEX, we utilized the Oracle EBS TCA public PL/SQL APIs to create and update customers. And because APEX is in the same database as Oracle EBS, we could query customer data directly from the customer tables. This integration minimized duplicity and ensured Oracle ERP remains the source of truth for all Customer records.

We also took advantage of EBS features such as lookups and address-style and tax-code formats so we didn't have to maintain them in two different places.

2. Second design principle: when we built the web app, we built the customer creation process as a workflow to drive user behavior.

• In the new APEX app, Customer Search was no longer optional. To create a new customer, users must type the customer name in a field and press submit. The algorithm would then return a listing of possible matches, along with a match score.

• Each possible customer match was a link that, when clicked, displayed customer details via a pop-up with essential fields users rely on to determine if this is the customer they need

• Suppose the customer is indeed the one the user needs. In this case, the user is allowed to perform edits as needed or, with the click of a button, automatically be navigated to the sales order form with that customer already populated on a new order

• Otherwise, if the customer is not found, the user would select a button we named "Customer Not Found, Proceed With New Customer". By naming the button in this way, we force the user to review potential duplicates and acknowledge that a duplicate does not exist.

The Results

Performance

In Production EBS environments with up to 10,000 customers, it took no more than two seconds for the Jaro-Winkler algorithm to return search results. That's pretty impressive, considering the algorithm calculates and returns a match score for every customer record in the Customer Master.

If a client ever had over 100,000 customers, one could tailor the solution by introducing filters to limit the search to only customers of a specific profile class, country, or other classification. Such a filter would take careful consideration because you could end up filtering out a duplicate classified incorrectly. I'll share in my next blog tactics to improve performance and match score results by using filters, removing common business terms such as "The", "Inc.", "Incorporated", "LLC", and "Limited" from the search and introducing additional algorithms.

For example, Oracle DB also supports sound and phonetics-based matching via the SOUNDEX function. In our case, we are solving for misspellings and lack of auto-enforced standards such as "Inc." versus "Incorporated", and thus, "approximate string matching" addressed our use case well enough. However, laying such an algorithm on top of Jaro-Winkler should, in theory, improve the match score.

Business Impact

1. Benefits of a clean Customer Master compound over time every time. Take a look at these wins:

• Within months, duplicates trended to zero. Not having customers represented across multiple accounts improves the accuracy for each of the following:

  • Customer credit check - results in the improved vetting of customer creditworthiness

  • Customer sales - improves accuracy for trends and forecasting projections

  • Customer service - reps no longer have to guess which of the multiple accounts assigned to a customer to tag for a particular issue.

  • Customer marketing - improves reach for marketing campaigns and loyalty programs

  • Customer reporting - results in more accurate reporting for gross profit and operating margins

  • Customer sales rep compensation - results in more accurate calculations

2. The solution reduced the number of steps and clicks for creating and managing customers by over 65%. Per users, the solution also reduced anxiety as they could now rely on quantifiable search results.

3. And this one is my favorite: the solution was initially rolled out to just one division in the company. Word spread of this solution's success and we were asked to extend it to other divisions. There is no better measure of success than a repeat customer :)

Conclusion

The business impact spelled out above highlights the detrimental impact if your data, particularly your customer master, is not clean. This impact would also apply to vendors, products, raw materials, user logins, etc.

The beauty of this solution is that it not only replaces a reactive workaround (running the Customer Merge Process to address duplicates), it gets down to the root cause and addresses it.

Many methods, tools and algorithms are available to help tackle data duplicates in the enterprise. I hope the approach above inspires you with ideas and action to prevent duplicates in your environments too.

A high-quality application relies on thorough testing. Generating sample data fast is vital for keeping up with today's world of Agile and condensed timelines. Traditional methods for generating data have too many downfalls: manual manipulation of production data is slow and error-prone and 3rd party tools, require a fee-based model or if free, a compromise in features and support.

Enter Oracle APEX Data Generator (OADG), a SQL Workshop utility tool available in Release 22.1 (May 2022). It generates large volumes of data for you, in the millions, in multiple formats (CSV, JSON, SQL) utilizing a vast library of data types. Its simple UI and workflow, along with its price (it's free!), make it an all-around winner over the multitude of alternatives out there.

Continue reading to discover why I think OADG is great, why you should use it over other options and how to set up and use it. I've also thrown a section on hints and tips I picked up along the way along with features I would ❤️ to see in the future.

Why It’s Great

The new tool is feature-rich, compared to the alternatives, both free and paid. And it's just in its first version. Its features include:

• Generates data in multiple formats (JSON, CSV, SQL)
• If you prefer, it inserts data directly into your existing table(s)
• Generates a million rows of sample data, with and without complex formulas, within 5 minutes
• Supports functions available in SQL for data transformations and derivations such as:
  • DB functions, e.g., TRIM, LPAD, RPAD, CASE, CONCAT
  • DB PL/SQL functions, e.g., DBMS_RANDOM.value
  • your own custom PL/SQL functions
• Supports use of SQL query results to populate your columns
• Supports foreign keys to generate consistent data across your tables and columns
• Supports the reuse of previously-defined data definition templates, known as blueprints, so you can generate data over and over again
• Provides ability to preview your data while you are building out the definition

• Provides a vast library of data types to generate sample data including date and time, integers, boolean, products, persons, plants, food, cars, animals, etc. And for each data type, a series of attributes are available to provide context to your data. For example,

  • Persons data type includes attributes such as first name, last name, biological sex, email address, etc.
  • Airport data type includes airport type, city, country, latitude, longitude, etc.
  • Car data type includes make, model, drivetrain and many others as illustrated in screenshot below:

APEX makes the sample data types and their respective values available to query via the the GET_EXAMPLE function. For example, the query below will generate all cities available for the data type "airport":

select * 
from apex_dg_data_gen.get_example
           (p_friendly_name => 'airport.city', p_rows => 100);

The p_friendly_name variable may be found in the app declaratively:

I downloaded the APEX 22.1 Install and found the script that generates all the data types, attributes and values. You can view all sample data here.

• And if the above data types do not meet your needs, BYOD - import your own data and let the OADG transform it as needed.

Why Your Team Needs OADG

TLDR - Because it saves time. Testers no longer have to search or wait for data.

Oracle ERP, APEX and other app implementations typically require a combination of the following for testing:

• Custom Code - developers build PL/SQL packages to generate large numbers of records for volume testing
• Excel Hell - analysts and end users download a copy of Production records into Excel and then apply a series of formulas and functions by column to generate unique records. Users then hand-off to developers to load the records into the app or interface.
• 3rd-Party Tools - hundreds of open source (free) and pay-as-you-go tools are available for generating test data. However, you need to consider factors like supported databases, data generation methods, data types available, cost and support.

OADG allows your team to bypass all these concerns, and what's more, it's free, fast and easy to use.

A quick note on reusing Production Data - relying on production data introduces risk as this data typically represents 'perfect' data that has already been vetted. To thoroughly test your new app, integration or business logic, your test data needs exceptions, anomalies, negative outliers and other invalid data to rigorously prove out your app and any ETL routines.

Be a hero and provide them OADG!

Tip: Data Generation tools are typically not applicable for ML use cases as you do not want to feed algorithms randomly-generated data. You need some data correlation across your columns so your algorithm can learn.

Setting up & using OADG

The best way to illustrate this feature is through an example. We'll use a simple Product table with a relational dependency to the Product Categories table:

Here's a visual of the workflow for data generation:

1. Create Blueprint

As depicted in the workflow above, the first step to generating data is to capture the definition of your tables and columns via a Blueprint, a template-like object which stores the settings, transformation rules and data sources for your columns.

OADG provides three methods for creating a blueprint. A wizard-like flow guides you through each method, as screenshot illustrates below.

Navigation: SQL Workshop > Utilities > Data Generator

There are benefits to each method:

1. Use Existing Tables - this option provides you with two big features: 1) it auto-generates your blueprint based on your table's definition, and 2) if you choose, it will automatically load the generated sample data directly into your existing table.

2. From Scratch - this option provides you ultimate flexibility in the sequence of your table(s) and column(s) and will provide you generated data in a CSV, JSON or SQL file.

3. Import JSON File - this option serves as my ultimate 'edit' recourse. I typically generate a blueprint from scratch or from an existing table and if I need to edit the sequence of a table or column, I export it as a JSON, make the edits I need, and then reimport it with this option.

2. Define each column's data source

This is where you define the data you want to generate and how to transform it. Once you have defined your table(s) and column(s) with guidance from the wizard in step 1 above, click on your first column to display its Column and Data Source regions, as illustrated in screenshot below.

NOTE: I have uploaded my blueprint's JSON here in case you'd like to follow along.

OADG makes available six data sources, providing almost unlimited flexibility for data transformation.

Let's see each of these in action below.

1. Blueprint

This option allows the relational dependency (foreign-key) between tables. For my use case, I need to reference the CATEGORY_ID from the PRODUCT_CATEGORY table to the CATEGORY_ID in my PRODUCT table.

Tip: this option is only displayed if you have if you have more than one table defined in your blueprint. If you need to reference Table A.Column A's values for your Table B.Column B, ensure you define Table A and its columns before defining Table B in the Blueprint. This feature is sequence-dependent and will force you to redesign the sequence of your tables if they are not in the right order.

2. Custom Data Source

Select this option if the data generator needs to randomly assign values from your own provided data. Simply create a custom data source by selecting the hamburger bar as shown below:

For my example, I uploaded a CSV file with 1000+ retail brands using the Data Workshop utility. These values will serve as sample data for the BRAND column.

NOTE: The RETAIL_BRANDS.xlsx file I use in this example is available here.

3. Built-In

This source option allows you to use any of the pre-seeded data types. I found myself running the "friendly_name" script provided in the "Why It's Great" section above a number of times to get me familiar with the data and its boundless possibilities.

I chose the Built-In option for five columns: CATEGORY_NAME, PRODUCT_NAME, COST, LAUNCH_DATE and ACTIVE. Here is a pic of the LAUNCH_DATE and ACTIVE column settings. Check out the convenience the "Date Between Min and Max" data type provides:

Other "Date" and "Boolean" options include the following:

4. Inline

This is a very handy option for when you have a manageable list of pre-defined values. Instead of having to load your custom data to a table, you simply list out your values in a table provided by this option. For my use case, I defined four values for the UOM column. See screenshot below.

Note the "Frequency" column above, which allows me to indicate the occurrence of one value compared to the others in a generated data set. Neat!

And Note the "Multi Value Options" fields as displayed in the screenshot below. It allows you to generate multiple values for a column. For this specific screenshot, I have instructed OADG to assign up to three values for the UOM column with a comma as my delimiter.

5. Sequence

As the name applies, this option will generate a numeric sequence for your column. It lets you specify the starting sequence number as well as the incremental value. I use this for both my CATEGORY_ID and PRODUCT_ID columns.

6. Formula

This one is my favorite because it's powerful and provides so much flexibility. It allows you to apply just about any function to transform built-in or custom data. You can apply a substring function to limit size of values, DBMS_RANDOM or CASE to derive values based on dependencies with other columns, as shown in the screenshot below:

Did you catch the Required flag setting on the screenshot above? If you set a column to not Required, you can indicate the percentage of values you'd like to be set as Null.

This was a quick overview of the six data sources available. You will spend the bulk of your setup in this section. With such flexibility, you can just about build anything you dream up.

3. Preview and correct as needed

The 'Preview' option provides a live preview of the data your blueprint will generate, giving you the opportunity to edit any of your column's definitions before generating your data. Here's a preview of my data. Because I have two tables defined, it provides me two views to review:

4. Generate data (CSV, JSON, SQL)

Finally, OADG offers three file output formats: CSV, JSON or a SQL script ready for upload directly into your table(s).

And here are a few pics of my results in each format.

Performance

As you can see, data generation is lightning fast for one million rows with eight columns, three of which had formulas. These test runs were ran in OCI Cloud free tier.

Heads Up

Here are a few tips and hints I thought I'd pass along:

• The sequence field is not updatable. To re-sequence a column, you will need to delete the column and recreate it in the position you need it within your table. You can perform this declaratively by right-clicking on the column to delete it and recreate it in the APEX Builder or, an easier option is to re-create the blueprint via JSON.
• If column dependencies between tables exist, it is important to sequence the tables correctly in the blueprint design. For instance, since my PRODUCT table has a dependency on a column in the PRODUCT_CATEGORY table, it is important to sequence the PRODUCT_CATEGORY table in my blueprint first, followed by the PRODUCT table. In my first run, I defined my tables in the wrong sequence. Since the sequence field is not updatable, I had to delete both tables to re-create them in the correct sequence. Alternatively, I could have exported the blueprint design, edited the sequence number in its JSON and then reimport it again.
• The option to load into existing tables is possible for blueprints created from scratch or based on an existing table. If you built your blueprint from scratch, your blueprint's table name must match the table name in your schema exactly and you must comply with typical table constraints such as ensuring your blueprint includes all required columns, etc.

• A blueprint is an all or nothing definition. If you have three tables in your blueprint, it will generate data for all three tables. If for a particular run, you want to create data for just one table, you will need to create a new blueprint because you are unable to temporarily disable the other tables. NOTE: A 'copy' or 'duplicate' blueprint button does not exist, but you can export your current blueprint, edit the JSON and import it back in.
• When designing your column definitions, it appears a column with a formula cannot reference another column with a formula. It appears each column is being evaluated independently. Although it did not throw out an error during my testing, the Preview results in my column were not correct.
• There can be a performance hit if your columns include very complex formulas. The higher the complexity, the bigger the hit.
• Don't skip the APEX Help sections - they provide great examples as they guide through the data generation process.

Add-Ons I Would Love To See

Release 22.1 (May 2022) is the first roll-out of the Data Generator and it is fully-robust as it is. I can't help but dream up of additional iterations the APEX team could deliver in future versions...

• Enable For Everyone - As it's currently an APEX Utility Tool, only developers and administrators have access to the data generator. But business analysts and other end users could benefit too. As designed now, end users have to request a developer to generate the data for them. Making it available outside the APEX Builder would allow users to use it without developer intervention. Alternatively, you could point users to apex.oracle.com so they could upload their own blueprints and custom data.
• Copy Blueprint Button - ideal for when I need a new version of my blueprint. Currently, I export my existing blueprint, edit it in JSON and re-import with a new name. This is not hard, but a button would require less clicks.

Summary

Hundreds of fee-based and open-source test data generation tools exist out on the market. When you consider the factors for selecting a tool such as the data types supported, data generation methods, sample data library, performance and cost, the Oracle APEX Data Generator comes out on top. Thanks Oracle APEX team. 🙏

Hashnode's biggest selling point for me is that it fully supports my personal domain for free. This means I get to continue to blog under my own name, sandra-suarez.com, while taking advantage of all the features the platform offers, including issuing and renewing an SSL certificate for me. No more renewing my Let's Encrypt SSL certificate every quarter :)

Hashnode's General-Purpose Custom Domain Support

Hashnode provides instructions to map your personal domain to your Hashnode Blog. They even provide detailed guides for GoDaddy, NameCheap and Cloudflare DNS providers. But not for AWS Route 53. At least not as of June 2022. I spent a few hours troubleshooting my setup and I'm sharing my lessons learned.

Why Route 53 Is Different

AWS Route 53 requires the additional setup of a hosted zone for your domain, something not required by other DNS providers. And the existence of such a hosted zone introduces the risk that the name servers at the hosted zone level may not match the name servers at the domain level. This was my problem.

1. Verify Name Servers Match

Problem: I had mismatched name servers between my registered domain and my hosted zone.

The Fix: Copy the name servers from the hosted zone over to my registered domain.

a. Make a copy of all domain name servers in your hosted zone.

b. Next, proceed to the registered domain section. Click on the "Add or Edit Name Servers" link under the name servers section and add all servers. You will need to add each one at a time.

c. After the change, you can verify your DNS propagation here. For me, I saw it start to propagate within minutes but it took a couple of hours for it to propagate everywhere.

2. Root Domains Require An Extra DNS Entry

When setting up your Hashnode blog, you will need to decide whether to point it to your root domain or a sub-domain. In my case:

• example of a root domain: sandra-suarez.com
• example of a sub-domain: blog.sandra-suarez.com

My personal site is specifically for blogging so I went the root domain route to keep things simple.

Because Route 53 does not support CNAME flattening, setups for a root domain will require an extra DNS entry compared to a sub-domain setup.

Hashnode provides a a handy table (see below) indicating whether your DNS provider supports CNAME flattening. If so, like in the case of Cloudflare, you only need to create a "CNAME" DNS entry. Route 53, on the other hand, does not support CNAME flattening, so two DNS entries are required: a "CNAME" and an "A" entry.

In the two screenshots below, notice how a root domain setup requires two DNS entries, "CNAME" and an "A" entry while a sub-domain requires only one.

Root Domain Setup Instructions from Hashnode

Sub-Domain Setup Instructions from Hashnode

And so for the case of a root domain setup, here is what these settings will look like in Route 53:

DNS record setup for sandra-suarez.com

DNS record setup for www.sandra-suarez.com

Here is the final setup of my DNS entries in Route 53:

3. Discrepancy between Hashnode's and Route 53's Instructions

You may have caught a discrepancy between Hashnode's instructions and Route 53's when it came to setting up the DNS entry for your root domain. See screenshot below.

As of today, July 3, 2022, in order for my blog to work, I need a DNS entry saved with an empty record name, as shown by Route 53's pic on the right. Creating a DNS entry that mimics Hashnode's setup on the left doesn't impact my setups, as long as I have an entry as suggested by Route 53. I verified this by first creating my DNS entries as described by Hashnode. When that didn't work, I added a DNS entry as described by Route 53. My blog now worked. I then removed the DNS entry with the '@' and found that my blog still worked. Finally, I re-ran these test scenarios to ensure my results were consistent.

Recap Of Considerations Above

To quickly summarize:

1. Decide whether you want your root domain or a sub-domain to point to your Hashnode blog.
2. In Hashnode - Follow Hashnode's instructions for custom domains, taking special note of setups for either a root domain or sub-domain mapping.
3. In Route 53 - Ensure the name servers between your registered domain and your hosted zone match.
4. For root domain mappings, perform these additional steps:
   • In Route 53 - Ensure you setup two DNS records, one for your root domain and a second one for "www" to redirect to your root domain. You only need one DNS record if you are pointing to a sub-domain.
   • In Route 53 - Ensure the record name of the DNS entry for your root domain is empty.

Happy Blogging

My hope is that this quick blog saves you time.

Like or comment below if this helps with the setup of your new blog. I look forward to viewing and following your blog.