JD Edwards Licensing FAQ

JD Edwards Licensing FAQ

Q1. What is JD Edwards perpetual licensing, and how does it differ from cloud or subscription models?

A1. Perpetual licensing means you purchase a one-time, permanent license to run the JD Edwards software on-premises instead of paying recurring subscription fees.

With a perpetual license, you can use the software indefinitely (typically paying annual support for updates). In contrast, cloud or subscription models involve ongoing payments for term-based use​. In other words, JD Edwards licenses give you a lasting on-premise usage right, and you own the software license outright.

This differs from Oracle’s cloud SaaS offering or BYOL (Bring Your Own License), which are subscription-based and not the focus here. Perpetual licensing is ideal if you want long-term on-prem control and are willing to manage the infrastructure, while cloud subscriptions trade upfront costs for ongoing fees and vendor-managed infrastructure.

Q2. Does JD Edwards EnterpriseOne licensing differ from JD Edwards World licensing?

A2. Both JD Edwards EnterpriseOne (the newer, multi-platform version) and JD Edwards World (the legacy IBM iSeries version) use on-premises perpetual licensing, but some terminology and modules differ. In both cases, licenses are primarily modular – you license each functional module (like Financial Management, Manufacturing, etc.) for a certain number of users​. For example, if you use World’s Financial Management, you must have a license for that module and know the total number of users accessing it​.

A System Foundation (or base foundation) license is a prerequisite for all modules in both product lines, usually requiring the same user licenses as the main modules​. The fundamental licensing metrics (user counts, etc.) apply similarly to EnterpriseOne and World. EnterpriseOne has a broader suite and more modern interface, but from a licensing perspective, both follow the perpetual, on-prem model with user-based licensing for modules. Oracle has stopped major new releases for World (latest is A9.4 with support until 2025), but existing World licenses remain valid perpetually​.

Q3. What are the common licensing metrics used for JD Edwards on-premises software?

A3. Oracle uses several key metrics to measure JD Edwards license usage. The main ones include:

• Named User – a license per named individual who can use the software (one license = one specific user).
• Concurrent User – licenses based on the maximum number of users using the system simultaneously (shared among users, counted at peak concurrent use).
• Application User – Oracle’s standard metric for many JD Edwards modules, counting each individual authorized to use the application (essentially a named user for application software).
• Processor (or core-based) – licenses are based on the number of processor cores on the servers where JD Edwards is installed, using Oracle’s core factor calculations. This metric allows unlimited users but ties cost to hardware capacity.
• Usage-based metrics—For certain modules, licensing may be based on a business metric like the number of Employees, Expense Reports, or Revenue rather than user count. For example, HR modules can be licensed per employee, and expense management can be done by the number of expense transactions.
• Enterprise metric – an enterprise license covers unlimited users enterprise-wide, priced by a high-level metric such as company revenue, number of employees, or cost of goods sold. (Enterprise licenses are less common and involve a broad usage agreement across the whole organization.)

These metrics provide flexibility in licensing JD Edwards. Most on-prem customers use an Application User (named user) model, but other metrics can apply depending on the module or contract.

Q4. What is a Named User license in JD Edwards licensing?

A4. A Named User license is a per-person license assigned to a specific individual (username) who can access JD Edwards. Each named user license grants one person full use of the licensed JD Edwards modules.

In practical terms, if you have 50 employees who need to use JD Edwards, you would purchase 50 Named User licenses (per module or suite being used). Named User is considered a “full use” license: the user can access all functionality of the modules for which they are licensed. This straightforward metric works well for users who regularly use the system.

Remember that a named license cannot be shared among individuals; even if the named person is not using the system at a given time, no one else can use that license. (Oracle’s current terminology for application software is often Application User rather than Named User, but the concept is similar to the traditional named user definition.)

Q5. What is an Application User license, and how is it used in JD Edwards?

A5. Application User is the primary user-based licensing metric Oracle uses for JD Edwards modules. An Application User is an individual authorized by you to use the JD Edwards application, regardless of whether they are actively using it at any given moment.

This means every person with credentials/access to JD Edwards counts as an Application User. Most JD Edwards EnterpriseOne modules (Financials, Manufacturing, CRM, etc.) are priced per Application User. For example, if you license the Inventory Management module for 20 Application Users, you can authorize 20 people to use that module.

Application User licensing is essentially a named user model tailored to Oracle applications – it counts unique users, not concurrent sessions. Oracle often sets a minimum number of Application User licenses per module (commonly five users minimum).

In summary, you need to purchase an Application User license for each person who will access a JD Edwards module or suite, and this metric is the most common way JD Edwards software is sold.

Q6. How does processor-based or core-based licensing work for JD Edwards?

A6. Processor-based licensing ties the cost to the server hardware rather than individual users. In this model, you purchase licenses for each processor (CPU) or core on the servers where JD Edwards is installed. Oracle defines a “processor” for licensing using a core factor (each core is a fraction of a processor unit based on CPU type).

For example, if your JD Edwards server has eight cores and Oracle’s core factor for that processor type is 0.5, you would need four processor licenses (8 * 0.5). Processor licensing allows unlimited users to access the system as long as the hardware is licensed. It’s typically used when the user count is very high or difficult to track (for instance, if you have a large customer-facing deployment or thousands of infrequent users).

However, it can be expensive for large servers so that you would compare the cost of processor licenses vs. user licenses. Oracle sometimes imposes a minimum user count when licensing by processors (Named User Plus minimums per processor).

However, pure processor metrics for JD Edwards modules are less common than for Oracle Database. You might consider processor licensing if you anticipate a broad or unpredictable user base and want simplicity in compliance (ensuring your servers are licensed covers all usage).

Q7. Are there usage-based licensing metrics in JD Edwards (e.g., by employees or transactions)?

A7. Yes. In addition to user-based and processor metrics, some JD Edwards modules use alternative units of measure based on business usage.

For example:

• Human Capital Management (HR/Payroll) modules are often licensed by Employee count (all employees in your organization). Instead of buying per-user, you pay for the total number of employees since all are typically managed in the HR system. For instance, if you have 500 employees, HR might be priced at a rate per employee for 500 employees.
• Supply Chain Management components have been licensed based on $M Cost of Goods Sold (COGS) for some products. This license is tied to the volume of business (for example, a manufacturing company might license a supply chain planning tool per $X million of COGS).
• Expense Management is licensed by the number of Expense Reports processed annually. For instance, you might buy a block of licenses allowing up to 1,000 annual expense reports. This is a true usage metric: if you exceed that number of expense reports in a year, you’d need additional licenses.

These metrics let you align costs with usage drivers. Oracle’s JD Edwards price list explicitly defines these units. For example, expense reports are counted per 12-month period, and employees are defined as all full-time, part-time, contractors, etc., who are tracked in the system. Usage-based licensing is useful to avoid counting individual users in scenarios involving virtually everyone in the company or a large volume of transactions.

Q8. How are JD Edwards modules licensed – individually or as bundles?

A8. JD Edwards on-premises software is typically licensed on a component (module) basis, meaning you pick and choose the functional modules you need and license each separately. Oracle offers an “a la carte” component pricing model where you pay for individual modules (e.g., General Ledger, Accounts Payable, Inventory Management, etc.) by the number of users (or other metric) you need for that module.

This gives you the flexibility to license only the functionality your business requires, helping you avoid over-licensing by buying an entire suite if you don’t need every part of it. Each module has its licensing cost metric (usually Application User with a minimum quantity).

Alternatively, Oracle also provides bundled licensing options. For example, JD Edwards used to offer Suite-based or Solution-based pricing where a group of modules (a suite) would be licensed together for a set number of users.

However, the most common approach in modern Oracle contracts is component-based pricing (with Custom Application Suite and Enterprise options available as well – see below). In summary, you usually license JD Edwards by individual modules, and each module license specifies how many users (or what usage metric) you are entitled to for that module. Always ensure you also license the required foundation or prerequisite components and the modules (see Q12).

Q9. What is Oracle’s Component (A La Carte) pricing model for JD Edwards?

A9. Component pricing (a la carte) is Oracle’s flexible licensing model, allowing you to license JD Edwards functionality per module. Instead of buying a big suite, you select specific components needed for your business. Each component has its price and is usually licensed by the Application User (or another appropriate metric).

For example, you could license Financials, Manufacturing Management, and Inventory Management individually, each for a certain number of users, without purchasing other modules you don’t need. Oracle’s Global Price List for JD Edwards shows each module’s price per user and a minimum user count. The benefits of component pricing are cost control and precision – you pay only for what you will use.

Many JD Edwards customers use this model to avoid paying for entire suites. Remember that some modules have unique metrics in component pricing (e.g., Payroll by employee count, Expense by reports as noted). If your requirements change, you can add additional components later. Component pricing requires careful tracking to ensure all the modules are licensed for the appropriate number of users.

Q10. What is the Custom Application Suite (CAS) pricing in JD Edwards?

A10. Custom Application Suite (CAS) pricing is a licensing model where Oracle lets you bundle multiple JD Edwards products into a custom “suite” for a fixed number of users. Essentially, you negotiate a tailored package of modules your users will need, and you license that bundle for a certain number of CAS users. The cost is based on how many users will access the entire suite rather than licensing each module’s users separately.

Not all modules can be bundled into CAS deals – Oracle may restrict some components from being included, in which case those would still need separate component licenses. CAS pricing can simplify management if your users use a broad set of modules; you just track the number of suite users. It can also be cost-effective if you need many modules but have a smaller user base for each.

However, careful planning is required to ensure the bundle covers everything you need and that you’re not paying for unused components. In practice, CAS is less common than standard component pricing, but it’s an option if the standard metrics don’t fit your usage profile and you work with Oracle to structure a custom bundle.

Q11. How does Enterprise licensing work for JD Edwards?

A11. Enterprise licensing is a model that covers unlimited or organization-wide use of JD Edwards for a broad metric, typically used by large enterprises. Instead of licensing per user, an enterprise license is often based on high-level metrics like annual revenue, total employees, or cost of goods sold for the entire company. For example, a company might have an enterprise license allowing unlimited JD Edwards users across all modules, with the price determined by the company’s revenue bracket or employee count. The idea is to remove the need to count individual users or modules – you pay a big upfront (or annual) fee for the rights to use everything broadly.

The advantage is simplicity and scalability: Enterprise licensing means you won’t pay incrementally for each new user if you plan to grow or add many users. The downside is the high cost and risk of over-licensing if your organization doesn’t fully utilize the software. Enterprise licenses often make sense for large organizations or those expecting significant growth.

They usually involve a custom negotiation with Oracle. It’s also common that if you exceed certain growth metrics (like your employee count grows beyond a threshold), you might owe Oracle additional fees (“expansion fees” as historically seen in PeopleSoft enterprise pricing). In summary, enterprise licensing is “all you can eat” across the enterprise for JD Edwards, traded off against a large metric-based fee and careful contract terms.

Q12. Do JD Edwards modules have prerequisite products that also need to be licensed?

A12. Yes. Many JD Edwards modules require certain foundation or prerequisite licenses. The general rule is to license the prerequisite components in the same quantity (number of users) as the main module to be compliant​. Important examples of prerequisites​:

• System Foundation – This is the core platform license required for all JD Edwards EnterpriseOne modules. Every JD Edwards installation needs System Foundation licensed for the full user count as a base. (JD Edwards World has a similar World Foundation.)​
• Service Management Foundation – Required if you use Service Management or Capital Asset Management modules​. In other words, you cannot just license Capital Asset Management alone; you must also have Service Management Foundation licensed for the same number of users.
• CRM Foundation – Required for certain CRM modules like Case Management (and possibly others in the CRM suite)​. It provides underlying CRM capabilities on which those modules depend.

If you own a JD Edwards module but not its prerequisite, you are not properly licensed to use it (and likely it wouldn’t function fully without the foundation component). A common compliance issue is licensing a module like Service Management without realizing you also need the foundation license​.

Always ensure that you check Oracle’s licensing documentation for any prerequisite products for every module you license and match the user counts accordingly​. Oracle’s contracts usually list these dependencies. Missing a prerequisite or having fewer licenses for it than the main product will put you out of compliance. Essentially, the number of licenses for a prerequisite product must match the licenses for the associated primary module​.

Q13. How do I determine the user licenses I need for JD Edwards?

A13. To determine how many user licenses you need, you must count the individuals who will access the JD Edwards system under each licensing metric:

• For Application User (or Named User) licensing, count every unique person authorized to log in to JD Edwards. This includes full-time users, part-time or occasional users, and any contractors or others who will have a login. Even if a user only needs read-only access, if they have a login and use the JD Edwards application, they typically require at least an appropriate user license. The key is authorized users – if someone has credentials to use the software, they count as a user license, regardless of how often they use it.
• For concurrent user licensing (if applicable to your contract), estimate the maximum number of users using JD Edwards simultaneously. For example, if you have 100 potential users but at most 40 are logged in concurrently at peak, you would need 40 concurrent licenses. Monitoring system usage or using Oracle’s tools can help determine this peak.
• For Employee-based metrics (e.g., HR module by employee count), you count the total number of relevant employees. Oracle’s definition of “Employee” is broad: it includes all full-time, part-time, temporary workers, and contractors that are tracked by the program. If a business process touches all employees (like payroll), you likely count all employees.
• For other usage metrics (like expense reports), use historical or projected numbers to size the license (e.g., if you process ~800 expense reports a year and the license comes in blocks of 1,000, you’d need one block).
• For processor licensing, identify the servers where JD Edwards will run and count the cores according to Oracle’s processor-core factor table to determine the number of processor licenses.

Remember that if you have multiple modules, each module’s user count should be licensed appropriately. Often, you will license the same number of users for all modules that a particular set of users will access.

Also, include any external users needing direct access (see Q15 and Q23) in your counts. It’s good practice to slightly overestimate if you expect growth, but avoid gross over-licensing. A periodic review of user activity can help right-size the number of licenses you maintain.

Q14. What counts as “access” to JD Edwards for licensing purposes?

A14. In Oracle’s terms, any individual authorized to use the JD Edwards program needs a license. “Access” is not strictly limited to logging in via the main GUI; it can include any use of JD Edwards functionality. Key considerations:

• Suppose a person has a JD Edwards user account or is otherwise allowed to interact with the software (even indirectly). That typically constitutes access requiring a license. It doesn’t matter if they use it actively every day or once a month—the authorization alone counts.
• Read-only access (inquiry) still usually requires at least an Inquiry User license (see Q22) because the person uses the system’s data. Just viewing reports generated from JD Edwards wouldn’t count, but if they log in to JD Edwards to view data, that’s access.
• If you have integrations or a portal that pulls data from JD Edwards for users, be careful. Oracle’s policy on multiplexing says that if users access the software through any intermediate system, you still must count each end-user as a named user. In other words, you cannot avoid licensing by having a third-party app or web portal in front – all human end-users hitting JD Edwards functionality count. For example, 100 employees using a web portal that fetches JD Edwards data are 100 users in Oracle’s eyes (the “front-end” users must be licensed).
• Non-human access: Devices or automated processes (like IoT sensors updating JD Edwards) could fall under separate metrics (e.g., Connected Device licensing), but if those devices are simply updating data without human interaction, Oracle may count each device as a “user” in the case of Named User Plus. Typically, JD Edwards modules list a Connected Device metric for such scenarios.

In summary, anyone or anything that uses JD Edwards application logic or data to interact with the software’s functional capacity needs to be considered. It’s safest to assume every login account = 1 required license. Always refer to Oracle’s definitions in your license agreement, as they define a licensable user or device.

Q15. How are internal users versus external users licensed in JD Edwards?

A15. From a licensing standpoint, Oracle generally requires all users, whether internal (employees and contractors) or external (like customers, suppliers, and partners who access your system), to be properly licensed if they use the JD Edwards software.

However, the type of license or model can differ:

• Internal users (your employees, staff, and on-site contractors) typically need standard user licenses (Application User or Named User licenses) for the modules they access. As discussed, these are counted on a per-individual basis. Oracle’s Employee metric (for modules like HR) explicitly covers internal personnel.
• External users (third parties like customers, vendors, and franchisees) who log in to JD Edwards may also require licenses. Still, Oracle has introduced the concept of self-service users for certain scenarios. For example, JD Edwards has specific modules like Customer Self-Service or Supplier Self-Service, which are intended for external parties. These are often licensed differently. According to historical licensing, an external self-service user was treated “similar to a concurrent user” – meaning you don’t buy a license for each named customer, but rather license the functionality for external use in aggregate. For instance, Customer Self-Service might be licensed for a set number of concurrent sessions or simply a flat metric with a minimal user count (Oracle’s price list shows a minimum user count, e.g., five users, for Customer Self-Service module, suggesting you license the module itself and that covers external usage up to a point).
• Internal self-service (like Employee or Manager Self-Service modules) are usually licensed per user (similar to named user) because those users are your employees.
• In practical terms, if external users are just consuming information (like looking up order statuses through a portal), many organizations cover that by licensing the appropriate self-service module or ensuring the JD Edwards environment they connect to is licensed by processor/cores. Some choose processor-based licensing for external-facing environments to avoid tracking countless external usernames.

It’s important to clarify with Oracle how external user scenarios should be licensed in your case. Generally, an external person with credentials in your JD Edwards system should be counted under some license. Oracle’s contract might not require you to name each customer in the license count. Still, you may need a sufficient metric (like enough concurrent user licenses or a processor license) to cover that usage. Always review the specific self-service licensing terms for modules like Customer Self-Service or Supplier Self-Service if you use them, as these outline the rights for external users.

Q16. How are JD Edwards Financial Management modules licensed?

A16. The JD Edwards Financial Management suite typically includes General Ledger, Accounts Payable, Accounts Receivable, and related financial modules (sometimes just sold as “Financials”). These are usually licensed on a per-user basis. Oracle’s price list shows financials licensed by application users with a minimum of 5 users. This means you purchase a block of user licenses for the Financials module. If you have 20 finance team members who need to use JD Edwards Financials, you would get at least 20 Application User licenses for Financials (subject to the minimum). Those users can then access all the functionalities within the Financial Management suite that you’ve licensed.

Often, Financial Management is considered a core module set; to use it, you also need the System Foundation license. Also note, if you need Expense Management (employee expense reporting) that can be part of Financials – but Oracle sometimes licenses Expense Management separately by number of expense reports (as mentioned earlier). So, core financials (GL, AP, AR) is user-based, whereas certain sub-modules like Expense Reporting might have a different metric (Expense Report).

In JD Edwards World, you’d similarly license the Financial Management module for X users​. All users who perform financial transactions or inquiries should be counted. Always ensure modules like Accounts Payable, Accounts Receivable, etc., are covered under the Financials license or licensed individually if Oracle separates them (in EnterpriseOne, they’re usually bundled as one Financials product).

Real-world example: A mid-size company has 10 people in accounting and 5 in management who need to run financial reports – they might license 15 Financials users. Suppose some managers only view financial data occasionally. In that case, one might consider if those could be Inquiry User licenses (if offered). However, Oracle’s current model would still count them in the Application User count unless a separate Inquiry license is in your agreement (see Q22).

Q17. How are Manufacturing Management and Supply Chain Management modules licensed in JD Edwards?

A17. Manufacturing and Supply Chain modules in JD Edwards EnterpriseOne are also generally licensed per user (Application User metric), similar to other modules. For example, modules such as Inventory Management, Shop Floor Control/Manufacturing Management, Requirements Planning (MRP), Warehouse Management, Procurement, etc., all show licensing by Application User on Oracle’s price list. Each will have a price per user and a minimum number of users (often 5). You would purchase user licenses for each module according to how many people in your organization need to use that functionality.

Let’s illustrate: Suppose you have a manufacturing plant with 20 staff members who use the JD Edwards Manufacturing module (entering work orders and tracking production), and 15 also use Inventory Management. You would license Manufacturing Management for 20 users and Inventory Management for 15. If it’s largely the same group of users, you might license both modules for 20 users (so all 20 can access both). Typically, companies align the user counts for related modules to cover the same user base. Remember, you also must license the System Foundation and possibly a Manufacturing Foundation if there is one (EnterpriseOne doesn’t list a specific foundation for manufacturing beyond System Foundation, but JD Edwards World may have a Manufacturing Foundation module).

Supply Chain Management modules like Sales Order Management, Procurement, and Logistics (Transportation Management) are likewise per Application User. For example, Sales Order Management is priced per user with a minimum of 5. So if 30 people (e.g., sales reps, order entry clerks) need to use the Order Management module, you’d license 30 Application Users. The same goes for Procurement and Subcontract Management, Warehouse Management, and Transportation – each by user count.

In summary, manufacturing and supply chain modules are individually licensed, usually by user. Ensure you identify all the modules you use in the supply chain process (sometimes they are tightly integrated, and using one might imply another usage). Also, check for prerequisites: e.g., Quality Management might be included or separate; Agreement Management (for procurement contracts) is another module by user. Licensing should cover all users interacting with these functions, including planners, buyers, and warehouse staff using JD Edwards terminals, etc. If some users only inquire about data (like a plant manager just checking status), consider if a less costly license type is available (see Q22 about inquiry users).

Q18. How is Human Capital Management (HCM) licensed in JD Edwards?

A18. JD Edwards HCM (Human Resources, Payroll, Self-Service HR, Time and Labor, etc.) often uses an Employee-based metric rather than pure named users. Oracle’s pricing for EnterpriseOne HCM modules shows core Human Resources licensed per Employee. For example, Human Resources might be priced at a certain dollar amount per employee, with “All Employees” as the quantity—meaning if your company has 500 employees, you pay for 500 units. Likewise, Payroll is priced per Employee (all employees for whom payroll is processed). The idea is that these systems inherently involve all (or most) employees, even if not all employees log into JD Edwards.

In addition, JD Edwards provides self-service modules, such as Self-Service Human Resources (for employees to update their information or benefits), which might also be based on an employee metric or sometimes a lower cost per head. Indeed, the price list shows Self-Service HR with a per-employee metric as well. Time and Labor is another HCM piece licensed per Employee on the price list.

It’s important to note that “Employee” in Oracle’s definition includes not just full-time staff but anyone who is tracked or uses the system (contractors, etc.) – essentially your workforce. So, HCM licensing effectively covers your workforce population.

However, some HCM-related modules might still use user metrics. For example, One View Reporting for Human Resources is licensed per Application User (with a small number of users since only HR staff generating reports would need that). However, the main transactional parts of HCM (core HR and Payroll processing) use the employee metric.

In JD Edwards World, similarly, you would license HR based on the number of employees. If World doesn’t have an employee metric, you might instead license by Named Users (i.e., HR staff using the system), but Oracle’s standard now is employee-based for HR.

Always clarify which metric applies in your contract. For compliance, maintain an updated count of your employees because if your headcount grows beyond what you are licensed for, you’ll need to true up. Conversely, if the headcount drops significantly, you may be over-licensed (though typically, you can’t reduce your license count easily; you could reduce support costs for unused licenses).

Q19. How are Order Management and CRM modules licensed in JD Edwards?

A19. Order Management (Sales Order Processing) and Customer Relationship Management (CRM) modules in JD Edwards are licensed on a per-user basis (Application User), similar to other modules. For example, Sales Order Management – which covers entering and processing customer orders – is licensed per Application User. If you have, say, 15 users in sales operations entering orders, you’d get 15 user licenses for Sales Order Management (minimum 5 per the price list).

JD Edwards CRM functionality includes modules like Sales Force Automation, Customer Service/Case Management, Advanced Pricing (often considered part of sales/CRM), and CRM Foundation. These are also priced per user. The price list shows, for instance, Advanced Pricing and Case Management, each with an Application User metric (again with a minimum of 5 users). That means you need to count each user (e.g., sales reps, customer service agents) who will use those CRM modules.

Remembering the CRM Foundation module: it’s a prerequisite that provides base CRM functionality (needed for Case Management, etc.)​. You must license CRM Foundation at the same user count as the CRM modules that depend on it.

Additionally, JD Edwards has Customer Self-Service and Partner Self-Service modules, which enable external parties to interact (checking orders, etc.). These, as mentioned, are licensed like self-service – typically by a small number of named or concurrent users to cover many external users. For example, Customer Self-Service on the price list is an Application User metric with a minimum of 5, which implies you can allow your customers to self-serve with a relatively small license purchase (Oracle expects external usage to be handled via that module without counting every customer as a user license individually).

In summary, for internal CRM and order management, count up your sales team, customer service team, pricing analysts – anyone who will use JD Edwards for sales orders, customer info, case tracking, etc. – and license that number of users for each module they need. Don’t forget prerequisite modules like CRM Foundation or Customer Service Management (if separate). And if you expose JD Edwards CRM data to customers or partners (through portals), ensure you have the appropriate licensing for those external interactions (either via the self-service module or by covering them with hardware/enterprise metrics as needed).

Q20. How are JD Edwards Project Management modules licensed?

A20. JD Edwards has robust project management capabilities, including modules like Project Costing, Contract and Service Billing, Advanced Contract Billing, Job Forecasting, etc. The component pricing model licenses these modules per user (Application User). For example, Project Costing is listed with an Application User metric (minimum five users).

So if your company uses JD Edwards for project accounting/cost management and you have, say, eight project controllers who use it, you’d license eight users for Project Costing (noting the minimum might require you to purchase 10 if that’s the floor, but Oracle’s list shows min 5 in this case).

Other project-related modules like Advanced Contract Billing or Homebuilder Management similarly show per-user licensing. You would count the users (project accountants, project managers, billing clerks, etc.) who need those functions.

If you are using a bundle like Project Management Suite, that might allow licensing multiple related modules together, but in component terms, each of these is separate. Also, Project Management often ties in with Financials (for project accounting)—those using Project Costing likely also use the General Ledger, but the GL usage would be covered under your Financials license.

One specialized note: JD Edwards has industry solutions like Homebuilder Management (for construction projects), which is again by user, and Resource Assignments, which also shows up on the price list by user. Identify which specific project modules you’ve installed and purchase licenses accordingly.

Since project modules are typically used by a limited group (as opposed to something like HR, which touches everyone), companies often license just a small number of users here. Keep an eye on any One View Reporting modules for Project Management. For example, One View Reporting for Project Costing is a separate line item (also per user)​intended for reporting users who need advanced reports on project data.

Q21. How are Asset Lifecycle Management and Real Estate Management modules licensed?

A21. Asset Lifecycle Management (ALM) in JD Edwards includes modules like Capital Asset Management (CAM), Maintenance (Equipment/Plant Maintenance), and related tools for managing assets and equipment. Real Estate Management (JD Edwards Real Estate or Property Management) covers managing property leases, rentals, etc. ALM and Real Estate modules are licensed per user (Application User) in the perpetual model.

For example, Capital Asset Management is listed with an Application User metric (minimum five users). If you have maintenance engineers or asset managers who use JD Edwards to track equipment maintenance, you’d license them accordingly. Similarly, Real Estate Management is also per Application User (min 5). If you manage properties and leases in JD Edwards and have three real estate managers using the module, you’d still need to buy the minimum five user licenses for Real Estate Management.

Often, these modules require a foundation: note that Service Management Foundation is a prerequisite for Capital Asset Management​, so you must license Service Management Foundation for the same number of users as CAM. Also, Resource Assignments (used in maintenance scheduling) appears as a separate module by user, which might come into play if you use that function.

All these fall under ALM in a broad sense. The key is to license every user who creates or updates asset records, schedules maintenance, processes work orders, or manages real estate contracts in the system. If other staff only need to view asset information, consider whether an Inquiry user license can cover them. In current practice, those view-only users might still count under your Application User licenses unless Oracle offers a different tier (see Q22).

Q22. Can I have different user licenses, like inquiry-only or casual users, to reduce costs?

A22. Historically, JD Edwards (and PeopleSoft) offered different categories of users such as Full-Use (Named), Moderate, and Inquiry users at different price points. An Inquiry User (sometimes called a casual user) had read-only access – they could view data but not enter transactions. A Moderate User has limited functionality, performs only certain predefined operations, and does not have full transactional capabilities. These licenses cost less than a full-use license and were assigned to specific individuals (one license per user, like named users).

For example, an Inquiry user might be a manager who only runs reports or checks status, and a Moderate user might be someone who approves timesheets or does routine tasks. Companies could reduce licensing costs by assigning such licenses to those who don’t need full access.

However, Oracle’s current JD Edwards price list does not explicitly list “Inquiry” or “Casual” user licenses – the standard model is Application User (full) licenses for most modules. The concept of moderate/inquiry users comes from older licensing models (Solution/Suite pricing days and JD Edwards World). Oracle may allow this licensing if it’s in your contract, but it’s not typically advertised openly now. You might still have those user types if you have an older agreement. In modern practice, many customers manage with full user licenses and carefully control who gets access.

That said, one could negotiate or structure an agreement for limited-use users. Another approach is to use Concurrent User licensing (if Oracle permits it for your product set) to effectively share a smaller pool of licenses among many infrequent users, achieving a similar cost savings goal for casual access.

In summary, yes, JD Edwards had the concept of inquiry-only or limited users, which cost less. If you have them, ensure those users have only limited permissions (using security to enforce that they don’t perform unlicensed activities). If you do not have such licenses but have many light users, talk to Oracle or a licensing expert – possibly a different metric (like a per-report or per-employee metric) could be applied, or consider concurrent licensing if available. Always document any special user category in your contract to be safe in audits.

Q23. Do external customer or partner users require JD Edwards licenses?

A23. Generally, yes – if external users (customers, suppliers, partners) are directly using your JD Edwards system, licensing needs to account for them.

Oracle’s licensing rules don’t distinguish between internal and external users in that anyone authorized to use the software should be licensed. However, there are special considerations:

• Self-Service Modules: JD Edwards provides specific modules for external facing use, like Customer Self-Service, Supplier Self-Service, Partner Portal, etc. These modules allow external parties limited access (for placing orders, checking data). Oracle licenses these so that you don’t need to buy a license for each external user, which would be impractical. Instead, they might be licensed per Application User with a small base number (e.g., five named users) or sometimes considered under a concurrent model. Essentially, by licensing the self-service module, you cover the usage by many external users under that umbrella. The external users are typically restricted to that module’s functionality (they can’t roam freely in JD Edwards).
• Named User Plus for external: In some Oracle products, external web users can be covered by a processor license or a maximum concurrency count. JD Edwards doesn’t explicitly have an “external user license” product, so you either use the self-service module licensing or cover them via an appropriate metric (like processor). For example, suppose you have a portal for hundreds of customers to check order status (and you’re not using a specific JDE self-service module). In that case, you might license the JD Edwards environment with enough processor licenses to allow unlimited external use, rather than trying to count each customer.
• Read-only external recipients: If external parties only receive outputs (like emailed reports or printed invoices from JDE), they do not need a license. Licenses are about accessing the software. So a customer receiving an invoice generated from JD Edwards is not a “user”. But if that customer can log in to a JDE portal to see the invoice or update info, they are an accessing user at that point.

It comes down to how the external party interacts. Plan for a licensing strategy if they have any form of login or direct query into your JD Edwards system. Oracle’s policy historically: internal self-service users are treated like named users; external self-service users are treated more like concurrent usage. This implies you should size for a plausible number of simultaneous external users or use technical metrics to cover it.

Always consult your Oracle rep to structure the appropriate licensing for external use cases and document any external use rights (some contracts explicitly allow external read-only use without additional license, etc., but that must be in writing). When in doubt, a safe route is licensing by processor or an enterprise metric to cover broad external access.

Q24. How can I monitor and track JD Edwards license usage to ensure compliance?

A24. Proactive tracking of license usage is crucial. Here are the best practices and tools for monitoring JD Edwards usage:

• Oracle License Management Services (LMS) Scripts: Oracle provides LMS scripts for JD Edwards EnterpriseOne environments. By running these scripts, you can extract data on how many users have accessed the system, which modules they’ve used, and other usage statistics. The scripts effectively capture usage over time, which Oracle auditors would look at. Running them regularly (e.g., quarterly) and reviewing the output can highlight if you’re nearing or exceeding your licensed counts.
• JD Edwards Security and User Reports: You can generate reports of all user accounts and their roles or usage within JD Edwards. For example, you might query the F00950 (for EnterpriseOne) to list active users or use the Work With User/Role application. Compare active user counts to your license entitlement.
• Third-Party Auditing Tools: Tools from third-party vendors (such as Q Software’s QCloud License Audit or other Oracle SAM tools) analyze JDE user activity and security setup to determine license requirements. These can automate the process of identifying how many users are using each module and even categorize usage (full vs. inquiry). They provide an independent check of compliance.
• Internal Monitoring: Establish an internal process to track new user additions or module activations. For instance, when a new employee is given access to JD Edwards, ensure that a license count is updated. If a new module is turned on for use, flag that a license must be in place.
• Periodic Audits: Conduct internal license audits at least annually (if not more often). This means reviewing how many licenses you have purchased vs. how many users are in the system and which modules they are touching. Compare this with your contract entitlements.
• Documented License Inventory: Keep a central record (spreadsheet or SAM tool) of all JD Edwards modules you have, the metric and quantity licensed for each, and current usage. Update it when any change occurs (new hire, user leaves, new module deployment, etc.).

By actively monitoring, you can spot issues early, such as if an unlicensed module was accidentally enabled or if the user count in a module is creeping above what you purchased. It’s much better to catch and address these issues before an official Oracle audit. Also, good records put you in a strong position to defend your usage or negotiate if needed.

Q25. Why should I conduct regular JD Edwards license audits internally?

A25. Regular internal license audits are highly recommended for a few reasons:

• Cost Optimization: Reviewing your usage might find you have more licenses than necessary (shelfware). Perhaps certain users no longer use JD Edwards or a module you licensed isn’t heavily used. An audit helps identify those and potentially allows you to reduce support costs or repurpose licenses elsewhere. Conversely, if you’re underusing some licenses, you might avoid buying more in areas where you can reassign existing ones.
• Compliance and Avoiding Penalties: Oracle can initiate a formal audit, and if they find you are using more than you bought, you could face back charges or penalties. Regular audits let you fix any internal non-compliance before Oracle notices. For example, if you discover 120 Financials users but only 100 licenses, you can proactively purchase additional licenses (or remove some users). Being prepared ensures no nasty surprises if Oracle’s License Management Services comes knocking.
• True-Up Budgeting: If your company is growing, regular audits will show the usage trend. You can budget for additional licenses in advance rather than scrambling when usage has already exceeded. Negotiating with Oracle for extra licenses outside of an audit scenario is easier.
• Process Improvement: Auditing often uncovers process issues, like forgotten user accounts that are still active or modules turned on that nobody should be using. Cleaning those up improves security and governance, not just licensing.
• Documentation for M&A or changes: Having up-to-date audit records is invaluable if there’s a merger, acquisition, or divestiture (see Q30). You’ll quickly be able to communicate what licenses you have and use.
• Support Renewals: Oracle support bills are based on licenses. You might decide not to renew support if you’re not using certain licenses. But you’d only know that through an audit.

Oracle’s own guidance stresses the benefit of regular self-audits: they help remain proactive rather than reactive, catching discrepancies internally. Ideally, make license audits a routine (like every six months). This way, by the time Oracle does an official audit (if they do), you have confidence that everything is in order and documentation to prove it.

Q26. What are common JD Edwards licensing pitfalls to avoid?

A26. There are several pitfalls that organizations should be careful to avoid in JD Edwards perpetual licensing:

• Over-licensing (buying too much): Sometimes, companies purchase more user licenses or modules than they use. This can happen due to misestimating needs or sales pressure to buy bundles. Over-licensing wastes budget – you end up paying support on unused licenses. For instance, buying 200 user licenses when only 150 users use the system. It’s a pitfall because it’s hard to “return” licenses later.
• Under-licensing (non-compliance): The opposite is also an issue—deploying JDE to more users or using extra modules without proper licenses. For example, giving a department access to a module that wasn’t originally licensed can lead to compliance issues and hefty fees if found in an audit. A specific pitfall is misunderstanding the terms, e.g., thinking an Inquiry user doesn’t need a license and then finding out they do.
• Miscounting users: Not counting all individuals who access the system. A common mistake is forgetting that indirect users or certain contractors need licenses. Or, assuming that if users are never concurrent, you don’t need licenses for all of them (unless you actually have a concurrent model explicitly, in which case you usually need to license named users).
• Ignoring prerequisites: A frequent compliance gap is when companies license a module without its prerequisite foundation or have fewer foundation licenses than module licenses​. For example, licensing 50 users of Capital Asset Management but only 10 of Service Management Foundation – that’s non-compliant. Always match those numbers (see Q12).
• Concurrent licensing confusion: A pitfall is not monitoring peak usage if you have concurrent user licenses. Exceeding the concurrent count (even if the total named users is within the limit) violates the terms. Conversely, some think they have concurrent rights when they purchased named users – assuming you can share logins, which is not allowed (each person needs their own named license).
• Multiplexing misunderstandings: As mentioned, using a middleware or portal and not realizing all end-users still count. Some might incorrectly only license the middleware account, but Oracle requires counting the end users. This pitfall can cause huge discrepancies if, say, 1,000 external users were accessing via a single service account.
• Over-customization leading to module creep: JD Edwards is highly customizable. Sometimes, customizations inadvertently use components of modules you didn’t license. For example, a custom program calls a function from a module you don’t own. In an audit, that could be flagged as usage of that module. Companies should ensure that customizations don’t accidentally require licensing additional modules.
• Not updating licenses after organizational changes: If your company grows by acquisition or a division starts using JD Edwards where they weren’t before, you need to update your licensing. A pitfall is thinking your old license covers new usage scenarios without verification.

Common sense and diligence help avoid these pitfalls. Oracle’s FAQ notes that over-licensing (buying too many Named User licenses) and misunderstanding concurrent limits are frequent issues. Regular training of your IT and procurement teams on these terms can help. When in doubt, ask for a licensing review or use a consultant to ensure you’re clear.

Q27. Can I mix different license metrics (Named User, Concurrent User, Processor) for JD Edwards?

A27. Yes, Oracle often allows a mix of license metrics to tailor the licensing to your needs. This means you could, for example, have some portions of your JD Edwards environment licensed by Named (Application) Users and another portion by Processors, or have a mix of Named User and Concurrent User licenses.

Real-world scenarios for mixing metrics:

• A company might license core modules (financials, manufacturing) by Named Users for their employees but also license an external-facing module by processors to cover unlimited customer access.
• Or you might have a base number of Named User licenses for your daily active users and then purchase a handful of Concurrent User licenses to cover occasional users beyond that. Your heavy users are named (each needs their license), but a pool of 10 concurrent licenses could be used by a rotating group of 30 infrequent users (only 10 at a time). This can be more cost-effective for those “sporadic” users.

Oracle’s flexibility in mixing metrics accommodates different use cases within one organization. However, note a few things:

• Not every metric is available for every module. For instance, Oracle may only offer the Application User metric by default for certain JD Edwards modules. Concurrent user metrics might not be officially on the price list but could be negotiated.
• If you mix metrics, the documentation should clearly state which licenses cover which users or systems. During an audit, you’ll need to demonstrate compliance separately for each metric.
• There may be minimums and ratios to maintain. For example, if you have Named User Plus (Oracle DB metric) and Processor mixes, Oracle often requires a minimum number of NUP per processor. In the JD Edwards context, if mixing, ensure you meet any such minimums or conditions specified in the contract.

In summary, a mixed approach can provide flexibility—many organizations use a combination to optimize cost. Just ensure that the combination is explicitly part of your licensing agreement with Oracle (don’t assume you can mix arbitrarily; it should be negotiated and written down). With a proper mix, you might allocate expensive licenses to those needing full access and use more generalized metrics to cover broad or unpredictable usage.

Q28. Can JD Edwards licenses be reallocated or transferred to new users or entities?

A28. Reallocating licenses to new users: Yes, if an employee who was a licensed user leaves the company or no longer needs access, you can reassign that license to another person internally. JD Edwards Named User/Application User licenses are typically not tied to a specific individual forever – they can be transferred to a replacement user, as long as the number of active users doesn’t exceed the number of licenses at any given time.

For example, if John was one of your 50 named users and he leaves, you can assign that user account/license to Jane as a new hire. Oracle’s policies allow this kind of reallocation. However, you should document the change (disable John’s access when you assign Jane, etc.) and ensure you’re not “rotating” a single license among multiple active users concurrently (that would violate terms). Oracle explicitly states that reassigning licenses is allowed when someone leaves or no longer needs access – just comply with one license per active user.

• Please note: if you have an older-style concurrent license, “reallocation” is inherent since concurrent pools are shared anyway.

Transferring licenses to another entity (company or subsidiary) is more complex. Oracle licenses are typically granted to a specific legal entity and its majority-owned subsidiaries. If you undergo a merger or acquisition, the licenses may not automatically transfer to the new entity without Oracle’s consent, depending on the contract terms​. For example, if Company A with JD Edwards licenses is acquired by Company B, can B use those licenses? Usually, yes, if Company A is now owned by B (so the licenses cover the new combined entity), but you should formally notify Oracle of the change. If you spin off a division, that new company might not have the rights to use the original company’s licenses unless negotiated.

Oracle’s contracts often include a “Transfer of licenses” clause. It might say that transfer outside the named licensee requires approval. Internal transfers are fine within the same corporate family; selling licenses to a third party is not allowed. So you cannot resell JD Edwards licenses on the open market without Oracle’s involvement.

If you need to transfer licenses due to reorganization, it’s best to:

• Check the contract for any transfer restrictions.
• Inform Oracle about the changes (especially in M&A scenarios) and get written acknowledgment if necessary.
• Keep records of any Oracle approvals for transfers or entity name changes.

In summary, internally reassigning a user license is fine and expected as staff changes (just maintain the one license per active user rule). Transferring licenses across corporate entities is possible only in line with contract terms (usually within the same company or its subsidiaries). Oracle’s consent may be required if a different customer uses it. Always play it safe and consult Oracle or a licensing expert during such events.

Q29. How can I optimize or reduce JD Edwards licensing costs without risking compliance?

A29. Optimizing JD Edwards licensing ensures you have the right number and type of licenses – not too many (waste) and not too few (compliance risk). Here are some best practices for cost optimization:

• Rightsize User Counts: Regularly review actual usage to see if all licensed users actively use the system. If you find many inactive users, you might reduce the number of licenses at your next renewal. Also, avoid “shelfware” by not licensing far more users than needed. For instance, if a department downsizes, consider reducing the licenses (which can lower support costs in the future since licenses are bought perpetually, but support is annual).
• Use the Appropriate License Type: If your contract allows for Concurrent User licenses and you have many occasional users, use concurrent licensing for those instead of individual named licenses. This can let multiple people share a smaller license pool, which is more cost-effective. Ensure you stay within concurrent limits, though. Similarly, leverage employee-based or transactional licenses where they make sense – e.g., if only HR uses JD Edwards, maybe licensing HR by employee count covers a lot of occasional self-service usage without needing a named login for everyone.
• Consider Module Necessity: License modules individually (component pricing), and only buy what you need. It sounds obvious, but sometimes, packages include extra modules that aren’t truly used. An internal survey of what features are utilized can reveal modules you can drop (or not purchase in the first place). Unused modules can be terminated from support (no ongoing cost) if you know you’ll never use them.
• Leverage Bundles or Enterprise deals strategically: If you foresee growth, it might be cheaper in the long run to go with an Enterprise Metric license covering unlimited users (based on a metric like revenue or employee count). This avoids incremental costs as you scale. However, don’t jump to this unless growth is likely, as enterprise deals are expensive upfront. Oracle sometimes offers deals if you consolidate many modules into an enterprise agreement.
• Monitor and Revoke Access: Have a process to remove JD Edwards access for employees who no longer need it (job role change, left the company). This keeps your active user count accurate. If someone leaves and isn’t replaced, that license could be not renewed if the overall count drops.
• Exploit Lower-Tier Licenses: If Oracle still honors Inquiry or Limited Use licenses for some users, utilize those for people who only need minimal access (they cost less, as discussed in Q22). You must ensure those users don’t exceed their allowed activities.
• Negotiation and Bargaining: When purchasing new licenses or renewing support, negotiate with Oracle. Sometimes Oracle may offer discounts for agreeing to longer support terms or if you are buying multiple products at once. Also, audit results (if you’re under in some area) might give you leverage to trade unused licenses for needed ones.
• Third-Party Support: As a last resort for cost savings, some companies consider third-party support providers (like Rimini Street) after they own licenses, which can cut annual support fees in half. However, you wouldn’t get updates from Oracle in that case, and it has implications beyond licensing itself.

In practice, regular audits and thoughtful license allocation yield optimization. For example, one strategy noted is to switch some heavy infrequent users from Named to Concurrent licenses where applicable and to drop unnecessary Named User licenses after reviewing access. Ultimately, maintain a close alignment between how your business uses JD Edwards and what you pay for – that alignment is the essence of license optimization.

Q30. How do mergers, acquisitions, or organizational changes impact JD Edwards licensing, and how should we handle it?

A30. Mergers and acquisitions (M&A) can significantly affect your JD Edwards licensing because the structure and ownership of the licenses may change.

Here’s what to consider and do in such scenarios:

• License Transferability: Oracle licenses are typically non-transferable without consent, except to subsidiaries or as allowed by contract. In an M&A, you must review the contract terms to see if licenses can be transferred or need renegotiation​. If your company (Licensee) is acquired, those licenses might transfer to the new owner as part of the assets, but Oracle often needs to be notified. If two companies with separate JDE licenses merge, you cannot just combine them and exceed counts unless you consolidate contracts with Oracle’s approval. Contract terms may restrict license transfers, so this must be handled carefully​.
• Consolidating License Agreements: If both companies in a merger have Oracle agreements, you’ll want to consolidate them under one master agreement if possible. This might involve aligning metrics (one company might have processor licenses, the other named user – Oracle may need to reconcile that)​. Engage Oracle early to develop a unified licensing strategy for the new entity​​.
• Changing Usage Footprint: Post-merger, the combined organization might have more users or eliminate duplicate systems. You need to assess the total number of JD Edwards users/modules the new entity will have vs. what was licensed separately. For instance, if each company had 100 licensed users, and after integration, you have 150 using JDE (some overlapping roles were eliminated), you might have excess licenses. Or vice versa, you might need to extend JDE to new users from the acquired company, requiring additional licenses.
• Legal Entity Name Change: If the company name or structure changes (e.g., you form a new LLC for the merged entity), update the license agreement to reflect the correct licensee name. Oracle’s approval is needed to assign licenses to a new legal entity if it’s not automatically considered a successor.
• Divestitures: If you spin off a division that uses JD Edwards, typically, that division needs to obtain its own licenses (it cannot keep using the parent’s licenses unless some transition agreement is made). Sometimes, as part of a divestiture, a license carve-out can be negotiated so the new company gets a subset of the licenses.
• Engage Experts: When M&A activity is happening, it’s wise to involve your Oracle account manager or a licensing expert. Oracle might offer a conversion or extension deal to ensure the new setup is compliant. They may waive certain fees if handled proactively, but an audit later could be problematic if ignored.

Conduct a comprehensive license audit during any organizational change to know exactly what you have and need​. Communicate with Oracle about the merger or acquisition to arrange any formal transfer or contract update​.

The key takeaway: licenses don’t automatically adjust to corporate changes – you must actively manage them to ensure the new organization remains compliant and optimally licensed. With careful planning, you can consolidate and optimize licenses in an M&A (for example, eliminating duplicate licenses or negotiating a more favorable enterprise license for the larger entity). Always keep documentation of communications and approvals regarding license transfers or changes during the process to have an audit trail​.

Do you want to know more about our Oracle Advisory Services?