What Is the Address Book in JD Edwards?
The Address Book is the master data backbone of JD Edwards EnterpriseOne and World. It is a single repository for every person, organization, location, and entity the ERP system needs to recognize. Customers, suppliers, employees, prospects, branches, plants, and internal entities like cost centers all sit in the same Address Book.
Each entry in the Address Book carries a unique identifier called the Address Book Number, or AN8. The AN8 is the foreign key that ties Address Book records to transactions, accounts, and operational records throughout the JD Edwards schema. If you see AN8 in a query, you are connecting back to the Address Book.
The Address Book is implemented primarily in the F0101 table, with extended attributes in related tables like F0111 (Who’s Who), F0115 (phone), F0116 (address), and F0150 (parent/child relationships). The structure is decades old and powerful, but it presents specific challenges for analytics teams trying to extract usable data.
Why the Address Book Matters for JD Edwards Analytics
Every analytics question about JD Edwards data eventually touches the Address Book. Who bought what? Address Book. Which vendor sent which invoice? Address Book. Who is responsible for which project? Address Book. Without resolving the Address Book correctly, downstream BI and AI reporting on JD Edwards data will misattribute transactions, double-count entities, or miss whole customer hierarchies.
For finance and operations teams, the Address Book is what turns a transaction-level data dump into a customer view, a vendor view, or a sales-by-rep view. For BI teams modeling JD Edwards data, the Address Book is one of the first dimensions built into a semantic model. Get it wrong, and every dashboard built on top inherits the error.
How the Address Book Works
AN8 as the universal key. Every Address Book entry has one AN8. Every transaction that touches that entity carries the AN8. Customers might have AN8 = 1001, vendors might start at 5000, employees at 7500. The numeric ranges are conventional, not enforced.
Search Types categorize entities. A Search Type code on each Address Book record indicates whether it is a customer (C), employee (E), vendor (V), prospect (P), or another category. Search Types are governed by a User Defined Code (UDC) list. They are how a JD Edwards user filters the Address Book to the right entity type.
Who’s Who records. The F0111 Who’s Who table holds the contact people associated with each Address Book entry. A single customer (AN8) might have ten Who’s Who entries for different contacts at that company. This is structurally important for CRM-style reporting and AI use cases involving customer engagement.
Parent/child hierarchies. The F0150 table stores relationships between Address Book entries. A parent customer can have multiple child entities for billing, shipping, or organizational rollups. Without resolving these hierarchies, customer-level analytics gets fragmented across what should be one account.
Effective dating. Many Address Book attributes can change over time and are tracked with effective dates. Reporting that ignores effective dating produces incorrect historical views.
The Address Book in Analytics and Reporting
Pulling Address Book data into a BI or AI environment is not as simple as querying F0101. Several patterns repeat in well-built JD Edwards analytics:
Resolve the AN8 to a name. Reports keyed on AN8 alone are unreadable. Joining the AN8 to the Address Book name field (Alpha Name) is the first transformation in every JD Edwards analytics pipeline.
Normalize Search Types. A consistent layer that exposes “Is this a customer, vendor, or employee?” makes downstream analytics dramatically faster to build.
Flatten Who’s Who appropriately. For sales analytics, surface the primary contact. For service analytics, surface all contacts. Embedded BI tools and AI assistants benefit from a clear Who’s Who model.
Apply parent/child rollups. Customer hierarchies need to be resolved into the semantic model so reports can aggregate by parent account, child account, or both depending on the question.
Handle effective dating. SCD Type 2 patterns work well for tracking how Address Book records change over time. This is critical for trend reporting that compares periods across multiple years.
Common Challenges and Best Practices
- Duplicate Address Book entries. Over years of operation, duplicate AN8 records for the same customer or vendor accumulate. Master Data Management is the long-term fix.
- AN8 reuse across entity types. Some shops use the same AN8 for a single entity that acts as both a customer and a supplier. Reporting that does not handle this case will misattribute transactions.
- Inconsistent Alpha Name formatting. “ACME CORP,” “Acme Corporation,” and “Acme Corp.” can appear as three separate entities to a query that has not been cleansed.
- Address Book security. Field-level security on the Address Book controls which users see which entities. Replicating this security in a BI environment requires careful design.
- Pre-built models accelerate the work. The Address Book transformations described above are well understood and consistent across JD Edwards deployments. Pre-built semantic models for JD Edwards handle Search Type normalization, AN8 resolution, Who’s Who flattening, and parent/child rollups out of the box.
Frequently Asked Questions
What is the difference between AN8 and Search Type?
AN8 is the unique identifier for a single Address Book entry. Search Type is the category code that tells you what kind of entity it is. Every record has both. AN8 is the key. Search Type is the classifier.
Where is the Address Book stored in JD Edwards?
The primary table is F0101. Related tables include F0111 (Who’s Who), F0115 (phone), F0116 (address), F0150 (parent/child), and F01151 (electronic addresses). All are connected via AN8.
How do BI tools work with the Address Book?
The Address Book becomes a dimension in the semantic model. Power BI, Databricks, or Microsoft Fabric semantic models translate AN8 codes and Search Type values into business-readable customer, vendor, and employee dimensions. Pre-built models for JD Edwards handle the most common patterns out of the box.
