Oracle JD Edwards Licensing Explained: User Types, Metrics, and Common Pitfalls

Oracle JD Edwards Licensing Explained

Executive Summary:
Oracle JD Edwards licensing can be complex, with various user types, metrics, and rules that enterprises must navigate. This article demystifies the JD Edwards license models for CIOs, ITAM managers, and procurement teams.

We explain the key license types (named users, concurrent users, etc.), newer metric-based licenses (enterprise metrics like per employee or device), and legacy user categories (like inquiry or moderate users).

Importantly, we highlight common contractual pitfalls – such as minimum license quantities and indirect usage – that organizations should be aware of to stay compliant and cost-efficient.

Key JD Edwards License Models and Metrics

Oracle JD Edwards EnterpriseOne (the modern JD Edwards platform) primarily uses user-based licensing models but offers some metric-based options for specific modules.

The main license models include:

• Named User (Application User) License: This is the standard model where each user who accesses a JD Edwards module needs their license. It’s a perpetual license tied to the person (and not shareable). If you have 50 Finance module users, you need 50 Finance licenses. This model is straightforward to understand and audit – one license per user per module – but requires careful tracking of user counts. Cost scales linearly with users, and every named login counts (even if they use the system infrequently).
• Custom Application Suite (CAS) License: A CAS license bundles multiple JD Edwards modules into one “suite” for licensing purposes. You buy a certain number of CAS user licenses; each user can use all modules in that suite. For example, instead of buying separate licenses for General Ledger, Accounts Payable, and Accounts Receivable for 100 users each, you might negotiate a Financials Suite CAS for 100 users covering all those modules. CAS can simplify management (one user count to track) and often comes with a discounted price versus licensing modules individually. It’s ideal when the same group of users needs access to many modules. However, it has a fixed user count – all 100 CAS users count for every included module, whether or not each uses every module, so you must size it wisely to avoid overpaying.
• Concurrent User License (Legacy): Historically, JD Edwards offered Concurrent licensing, though Oracle has phased it out for new sales. It allows a pool of users to share a limited number of simultaneous login slots. For instance, 50 concurrent licenses might cover an environment with 80 users, assuming no more than 50 are on simultaneously. It’s useful in shift-based use cases or where users have sporadic access, as it can reduce the total licenses needed. However, it requires monitoring – if the 51st user tries to log in, that’s a compliance breach if you only have 50 licenses. Also, concurrent licenses don’t differentiate by module; typically, they were sold per suite or system. Companies with older JD Edwards contracts may still operate under a concurrent model. New Oracle contracts encourage moving to named user instead.
• Enterprise Metric Licenses: Oracle offers licensing based on a business metric for certain JD Edwards modules, effectively allowing unlimited system users. Common metrics are “Employee” count (for HR or Payroll modules) or sometimes Revenue or other measures. If an Employee licenses, the cost is a set price per employee in your organization (usually all employees must be counted, including full-time, part-time, and relevant contractors). For example, if a Payroll module is $225 per Employee and you have 1,000 employees, you pay $225,000 for a perpetual license covering Payroll for the whole company. This model is advantageous if essentially every employee will interact with the system (directly or via self-service) because it simplifies licensing (no need to count named users) and protects you as you grow – you only need to true-up if you exceed the licensed number of employees. The downside is you pay for the metric regardless of actual usage – if you have many employees but only a few power users, a per-user model would be cheaper. Also, you must keep track of the metric (e.g., if the employee count grows beyond 1,000, you must inform Oracle and purchase additional blocks). Enterprise metrics turn licensing into more of a capacity planning exercise than a user-counting exercise.
• Device or Equipment Licenses: JD Edwards, especially in manufacturing or warehouse contexts, sometimes uses metrics like “Connected Device”. This would license devices (like barcode scanners, shop floor terminals, etc.) that connect to JD Edwards, rather than human users. For example, Oracle’s price list might say a device connection license is $460 (with a minimum of 50 devices). This metric is relevant if you have automated systems or many handheld devices interfacing with JD Edwards. Each device consuming a license means unlimited operators can use that device, but you cannot exceed the number of licensed devices. This model is more niche but important in certain industries.

Transactional Metrics: Additionally, a few modules use transaction-based metrics.

A prime example is an Expense Management module licensed by the number of expense reports processed (e.g., $6 per expense report, with a minimum of 1,000 reports licensed).

In such cases, you estimate the volume of transactions and license accordingly, trueing up if you process more. Transaction metrics shift the cost to actual usage volume rather than users.

Below is a summary table of these license models and how they’re measured:

*(Prices are illustrative list prices; actual negotiated prices are usually lower.)

Each model has pros and cons regarding cost predictability, administrative effort, and risk. Enterprises often use a mix, e.g., a named user for core ERP access, an employee metric for broad self-service functions, and maybe a device metric for certain IoT integrations.

User License Types (Full, Inquiry, etc.)

Beyond the broad models, JD Edwards historically defined different user categories that determine what a user can do.

While Oracle’s current licensing is simpler (mostly just “Application User”), if you have legacy agreements or are reading Oracle’s older documentation, you might encounter these user types:

• Full-Use (Named User): A standard licensed user who can perform all operations in their licensed modules. This is the default assumption for any application user license – full create/read/update/delete capabilities in the software.
• Inquiry-Only User: This limited license type allows users to view data in JD Edwards but not enter or update transactions. Inquiry users were often offered at a lower cost (because they had restricted usage). Before Oracle’s acquisition, JD Edwards had such distinctions, and Oracle’s PeopleSoft line similarly has “Inquiry” or “Employee Self-Service” users. Oracle doesn’t actively promote an “Inquiry User” license for JD Edwards EnterpriseOne today, but some customers still have them from the past. If you do have inquiry-only licenses, ensure those users truly have read-only access (enforced via software security) – if they perform transactions, you’d be out of compliance.
• Casual/Moderate User: A “Moderate” user (term used in legacy JD Edwards pricing) uses the system less frequently or only has specific, limited functions. It was an intermediate level between full and inquiry. For example, a moderate user can do a few daily transactions. Oracle’s modern licensing doesn’t include this concept explicitly, but organizations sometimes negotiate licensing for a batch of casual users in non-critical roles. In practice, unless spelled out in your contract, assume every named user license is full capability. Any internal categorization like “power user vs occasional user” is more for sizing licenses rather than a formal license difference.
• Self-Service User: Oracle sometimes distinguishes external or self-service usage, such as employees or partners using JD Edwards through a portal (for expense entry, timecards, or procurement requests). These might be covered by an enterprise metric (like all employees) or a separate license type. For example, JD Edwards had modules for Employee Self-Service where licensing is by employee count, not by named user. The idea is that these users have a limited scope (just their data entry or inquiries) compared to power users. Always check if a specific self-service module requires a certain metric license. The term “self-service user” is more prevalent in other Oracle apps, but it’s conceptually present in JD Edwards via those enterprise metrics for all employees.

Key point:

If your contract explicitly allows a type of user with restricted rights at a different price, then you can utilize that. If not, assume that any person logging in needs a standard license.

Buying only 10 licenses for 20 people is risky, assuming “they only use it a little.”

Oracle doesn’t base licensing on usage frequency (unless a special license type is in the contract); it’s based on having access, period. So, when in doubt, count every unique user.

Minimum License Quantities and Other Fine Print

Oracle’s licensing comes with fine print that enterprises must heed:

• Minimum Purchase Quantities: As mentioned, Oracle typically enforces a minimum number of licenses for each JD Edwards module or metric. For instance, most modules have a minimum of 5 named users required. Even if you have a small team 2 using a certain module, you’ll still need to buy five licenses. Device metrics might have a 50-device minimum, and some metrics like Employee might require “all employees” (meaning you can’t license just a subset of employees, it’s inherently all-in). These minimums ensure Oracle a baseline revenue for each product. When budgeting a new module, always check the price list or ask Oracle about the minimum – it might mean an up-front cost higher than you’d expect if your user count is below the threshold.
• Unlimited vs Restricted Usage: A JD Edwards license only entitles you to specific usage defined in the contract. That sounds obvious, but consider things like databases or middleware included – JD Edwards might come with a restricted-use Oracle Database license (in some cases) that is only for use with JD Edwards. Using it for something else violates the terms. Similarly, suppose you have an “enterprise license” for HR based on employee count. In that case, that doesn’t automatically cover a different module like manufacturing – each module or bundle is licensed separately, even if both are enterprise metrics. Don’t assume anything is unlimited across the whole suite unless explicitly stated.
• Geographical or Entity Restrictions: Ensure your contract covers your entire organization if needed. Some licenses might be sold per legal entity or region. Most modern Oracle contracts allow use by the purchasing legal entity and its majority-owned affiliates, but older ones might be more restrictive. If your company goes through mergers or divestitures, it could impact the licensing entitlements. Always align licensing scope with your corporate structure to avoid “accidental” non-compliance (e.g., a subsidiary using JD Edwards without a legal entitlement).
• Audit Clause and True-Up Obligation: In the previous articles, we touched on audit rights. However, regarding license rules, your contract likely obligates you to self-report any expansion beyond licensed quantities. That means if you knowingly exceed your user count or metric, you are supposed to inform Oracle and acquire more licenses. Of course, not everyone does this immediately, but it’s in the fine print. One reason to keep a close watch is that you don’t want Oracle to find it first. Also, if Oracle updates its definition of a metric (it sometimes refines definitions, like who counts as an “employee”), it usually informs customers. You must adhere to the new definition unless your contract is locked in the old one.
• License Assignments and Transfers: JD Edwards licenses are typically tied to your company and can’t be freely transferred. If you outsource a function, for example, and contractors will use JD Edwards, they usually need to use your licenses (they count as your users). You cannot transfer licenses to an outsourcing firm or another company. If you divest part of the business, splitting up the licenses requires Oracle’s approval. These are contractual nuances – just remember licenses are not physical assets you can resell or subdivide without Oracle’s consent (except in certain regions with specific laws). There’s no issue with internal moves (say, from one department to another) – licenses are company-wide.

Understanding these rules helps avoid unintentional breaches. Many CIOs have been caught off guard by a corporate acquisition doubling employee count (thus invalidating an “Employee metric” license limit) or assuming a small use didn’t need the 5-user minimum. Always read the ordering document and footnotes where these details live.

Common Licensing Pitfalls and How to Avoid Them

Even with understanding the models and rules, organizations make classic mistakes with JD Edwards licensing.

Here are some and tips to steer clear of trouble:

• Inactive Users Consuming Licenses: As mentioned, leaving old user accounts active can inflate your “usage” in Oracle’s eyes. Pitfall: Company A had 300 JD Edwards user licenses, but 50 of those users left over the last few years and weren’t deactivated. In an audit, Oracle counts 300 active accounts (maybe in reality, only 250 people who use it now work there). Solution: Regularly audit JD Edwards user accounts and promptly remove or disable no longer needed accounts. Maintain an accurate count of real users. This avoids over-buying licenses and shows Oracle you practice good housekeeping (which can be favorable during audits).
• Misunderstanding “All Employees” Metric: Some think that if not all employees log in, they don’t have to count all. For example, Company B licensed HR self-service for 1,000 employees, thinking only their office staff would use it. Still, they have 1,200 total, including field workers (even if those 200 never logged in, Oracle’s definition usually says if they could be tracked in JD Edwards, they count). Pitfall: under-licensing because you didn’t count every head per the contract definition. Solution: Always use Oracle’s contract definition to count metric licenses. If it says “all employees, including part-time and contractors with access,” you must include them. Negotiate the definition if something seems unreasonable before signing – after the fact, it’s binding.
• Enabling Unlicensed Modules in Software: JD Edwards is technically modular, but it doesn’t always hard-stop you from using an unlicensed module if installed. IT might install the whole suite for convenience. Pitfall: Users or IT testing a feature in a module you didn’t buy (like Advanced Warehouse or a different localization), which then shows up in audit logs. Oracle will consider that usage without a license. Solution: Only install or enable modules for which you have licenses. Use security settings to restrict access to any module you are unsure about. If you want to evaluate a module, get a time-bound trial license from Oracle or do it in a controlled way, not in production with real data.
• Concurrent License Overuse Not Monitored: A common mistake for those with concurrent licenses is not tracking peak usage. Pitfall: Company C has 100 concurrent licenses, but no one checked that peak usage hit 120 concurrent users at quarter-end after a new project went live. They only find out in an audit when Oracle sees logins exceeding 100. Solution: Watch concurrent sessions by using JD Edwards performance and user monitoring tools or logs. Some third-party tools can send alerts if concurrent sessions approach the limit. Also, consider a buffer – if consistently hitting near 100, reduce the allowed login count or get more licenses proactively.
• Customizations and Indirect Access: JD Edwards allows custom programs and integrates with other systems. A pitfall is assuming custom-built programs are exempt from licensing. For example, a company builds a custom web portal that pulls data from JD Edwards for vendors. Those vendor users didn’t log into JD Edwards directly, so the company didn’t license them. But Oracle could consider indirect usage requiring licenses (especially if the portal triggers transactions in JD Edwards). Similarly, a custom report that combines data from two modules might inadvertently require both modules to be licensed for the users running the report (because they’re effectively using both modules’ data). Solution: Treat interactions via any method as the user uses JD Edwards. If data or functions come out of JD Edwards for someone’s use, ask, “Do we have a license covering that person/function?” If unsure, consult your Oracle rep or a licensing expert. And when building custom reports or interfaces, ensure you’re not exposing functionality from modules you didn’t license. If you are, either restrict it or license it.
• Overlooking License Termination Impact: Some organizations clean house on licenses to save support fees without realizing the contract consequences. Pitfall: Company D decides to drop 100 unused licenses to save money, then finds their support bill for the remaining licenses didn’t go down much or at all, due to repricing. Or they later needed some of those licenses back and had to buy them at full price. Solution: Always engage Oracle about any changes to your license count. Sometimes, a better approach than terminating support is to keep the licenses (to avoid repricing) but try to repurpose them elsewhere in the organization, or negotiate a swap for other products. Avoid knee-jerk cancellations unless you’ve modeled the outcome.

By learning from these common pitfalls, a CIO can implement policies to avoid them. Essentially, meticulous management of who is using what, adherence to contractual definitions, and internal controls on system changes will prevent most licensing headaches.

Staying Compliant and Informed

To wrap up the discussion on JD Edwards licensing rules, it’s worth emphasizing that compliance is an ongoing effort.

Oracle’s licensing policies can be updated, and your business will evolve. Designate a role or team (often IT Asset Management or a software licensing manager) to stay on top of Oracle communications and price list changes, and periodically re-read your license agreements.

When Oracle releases new versions or changes the names of modules, double-check if there’s any impact on licensing. For example, if Oracle were to bundle new functionality into JD Edwards, would it be included for you, or would it count as a separate module requiring purchase? These nuances can slip in over time.

Finally, use available resources, such as Oracle’s own “Licensing Rules” documentation, user group forums, or advisory services.

JD Edwards is a mature product line; many have navigated these waters before – don’t hesitate to learn from their experiences. With solid knowledge and proactive management, you can maximize the value of your JD Edwards licenses and avoid the costly surprises.

Recommendations

• Catalog Your Licenses and Users: Maintain a detailed inventory of all JD Edwards licenses owned, including type (user, CAS, metrics) and any special user categories allowed. Map this against a current list of users and usage metrics so you always know your compliance position.
• Enforce “No License, No Access”: Implement a policy that no one can access JD Edwards unless a license is allocated. Automate this in your user provisioning. A license count check is required before creating a JD Edwards user account.
• Train Administrators on License Implications: Ensure system admins and developers understand the licensing impact of configurations. For instance, they should know that enabling a module or creating a generic account can have compliance consequences. A little training can prevent technical staff from inadvertently causing a licensing breach.
• Use Security to Segregate Usage: Leverage JD Edwards security settings to enforce license boundaries. For example, if you have inquiry-only users in your contract, set their roles to read-only in the software. If only 50 users are licensed for Module X, use security to ensure a 51st user cannot be added without approval. The system should reflect the contract.
• Monitor Employee and Contractor Counts: For enterprise metrics like Employee-based licenses, stay synced with HR on workforce numbers. If you’re nearing an employee count threshold, start planning budget or true-up discussions in advance. Don’t let a sudden hiring spree catch you out of compliance.
• Regular Compliance Audits: Internally audit your JD Edwards environment at least annually (more if there is a high change rate). Check user counts, module access logs, and any interfaces. Simulate an Oracle audit to see if you would pass. This practice will highlight issues early.
• Keep Contracts Accessible: Store all your Oracle contracts and ordering documents in a central repository and ensure relevant stakeholders can reference them. When questions arise (like “can contractors use our system?”), The answers are usually in those documents. Knowing your exact entitlements and restrictions is half the battle.
• Plan for Growth and Changes: If your business plans a merger, acquisition, or divestment, include the software licensing team in the planning. Major company structure or size changes can drastically alter licensing needs under metrics like employees or revenue. Negotiating an updated agreement with Oracle as part of that corporate change may be possible rather than facing compliance issues later.
• Stay Informed on Oracle Policy: Oracle may introduce new licensing options or updates (for example, they might one day formally offer a cloud subscription model for JD Edwards or change support timelines). You can adapt your strategy by staying informed through Oracle announcements or industry news. Sometimes new options can be leveraged for your benefit (or at least you won’t be caught by surprise).
• Engage Experts for Clarity: If there’s anything in your licensing that is confusing – e.g., definitions of a user type, or whether a certain integration counts as usage – don’t guess. Engage your Oracle account manager for clarification in writing, or seek advice from a licensing consultant. It’s better to get clarity up front than to discover an interpretation difference during an audit.

FAQ

Q1: What is a Named User license in JD Edwards?
A: A Named User license (also called an Application User license) means one specific individual is authorized to use the JD Edwards software (for the modules they are licensed for). It is tied to the person’s identity (usually their username). No matter how little or how much they use the system, they occupy a license. If that person leaves the company, you can reassign that license to another person, but you can’t have two people sharing one license concurrently. Essentially, each real human user equals one named user license per module. It’s the prevalent licensing mode for JD Edwards.

Q2: Can multiple people share a JD Edwards license if they don’t use it at the same time?
A: Not under a Named User model – sharing is not allowed. The only scenario where sharing was allowed is the Concurrent User license model, which is legacy. Concurrent licenses let multiple individuals share a pool of licenses, but even then, it’s limited by simultaneous use and requires that model to be in your contract. Unless you have that, you must license each person. Trying to have two employees use one login (to “save” a license) is a violation and would be flagged in an audit. It’s better to properly license everyone or explore if any limited-use options exist.

Q3: Does JD Edwards licensing require us to license our hardware or servers?
A: Generally, no for EnterpriseOne – you don’t license by CPU or server for JD Edwards application software. It’s user/metric-based. The mention of “Processor” licenses in some contexts usually applies to Oracle’s technology products (like databases) or historically to JD Edwards World (an older platform), which was licensed per machine. Oracle doesn’t sell JD Edwards EnterpriseOne by processor count. One nuance: if you use Oracle Database or other Oracle tech under the covers, those might need processor licensing depending on how you deploy them (especially if on virtualized environments). But the JD Edwards application does not increase cost if you run it on a bigger server, as long as your user counts remain the same. Always double-check the specific components – e.g., if using the Oracle WebLogic server, which also has separate licensing – but that’s outside JD Edwards application licensing.

Q4: What happens if our employee count exceeds what we licensed in an enterprise metric?
A: You are contractually obligated to inform Oracle and purchase additional licenses to cover the new band of employees (or revenue, or whatever metric). Typically, Oracle sells enterprise metric licenses in blocks. For example, if you licensed up to 5,000 employees and now have 5,500, Oracle might require you to buy an extra block, often something like a 500-employee increment. It’s important to negotiate the pricing of such increments when you first buy the metric license if possible (e.g., have the per-employee price locked or volume discounts pre-stated). Unfortunately, if your growth is temporary or seasonal, that usually doesn’t matter – an audit will measure the peak metric. Some companies purposely license a bit above current needs to have headroom and avoid immediate true-ups. Also, if you cross into a new revenue bracket (for revenue-based licensing), similar logic applies. Always refer to your specific metric definition and buying scheme in the contract.

Q5: Are any “free” licenses included with JD Edwards (for test environments or backups)?
A: Oracle’s general rule is you can use your licenses in any environment (dev/test/prod) as long as it’s for your internal use and doesn’t exceed the licensed counts. They don’t typically require separate licenses for non-production instances – the licenses are user-based regardless of environment. However, each actual user, even if just a tester, would count if they have access. If you don’t have one, Oracle sometimes includes a limited-use database license with JD Edwards for the underlying database. Still, that database is restricted to use only with JD Edwards. Always check the fine print: for example, the Oracle Database bundled for JD Edwards (if provided) can’t be used for other applications, or it triggers a license requirement. As for backup/failover servers, Oracle has rules about disaster recovery: usually, if the DR instance is cold (not actively used unless prod fails), you don’t need extra licenses. If it’s warm/active, you might. Clarify these scenarios with Oracle to be safe. However, JD Edwards application licensing is quite flexible regarding environments since it’s user-based – if the same 100 users use a dev and prod system, Oracle doesn’t charge twice. Just don’t exceed 100 in use.

Q6: Our contract mentions “CSUs” or “Custom Suite User” – what is that?
A: CSU stands for Custom Suite User, essentially the license for a Custom Application Suite (CAS). If you see terms like “XX CSUs” in your contract, you have many users licensed to use a defined bundle of modules. The contract should list which modules are in the custom suite. Each CSU is like a named user but has rights to multiple modules. It is important to know the count of CSUs you have and which modules they cover, and ensure you don’t add more users to that suite than are licensed. It’s also a hint that you might need additional licenses if you plan to use a module outside that suite or by users beyond those CSU users. Keep the suite scope documented internally so everyone knows what those users can access.

Q7: Can I convert my concurrent user licenses to named user licenses?
A: Yes, Oracle typically allows conversion (since they eventually want everyone on the modern model). The conversion usually involves a discussion with Oracle and likely some financial adjustment. You won’t get a 1-to-1 swap because concurrent licenses cover multiple individuals. Oracle might have a formula (for example, one concurrent = 1.5 named, etc., depending on usage). The goal in conversion is to end up properly licensing all actual users. Sometimes Oracle might give a compelling offer during an upgrade or contract renewal to convert concurrents to named (maybe with some discount or credit). If you have a stable concurrent setup that’s working and saving you money, you might hold onto it, but note that support on those might increase. Oracle might eliminate any grandfathered benefits over time. It’s worth evaluating if a conversion simplifies your compliance management and what the cost would be. Always negotiate – do not just accept a proposal; you might say “we’ll convert 50 concurrent to 75 named at X price,” etc., to ensure it aligns with your usage profile.

Q8: We have JD Edwards World (older system) – is its licensing different?
A: JD Edwards World (an older version primarily on IBM iSeries) had a different licensing model historically – often licensed by processor or by system rather than per user. For instance, World licenses could be tied to a specific hardware box (unlimited users on that box). If you are still running JDE World under an old agreement, those terms remain as-is for that product. However, if you migrate from World to EnterpriseOne, you’d likely move into the newer licensing models. Oracle has offered migration paths where you convert World processor licenses into several EnterpriseOne user licenses. This can be complex and something to negotiate. The main point: EnterpriseOne’s licensing (user/metric) doesn’t apply to World unless you actively convert. World customers need to watch hardware upgrades, though – if you had a CPU-based World license and moved to a more powerful server, check if you need to true-up the license. Because that’s a very specific scenario, always loop in Oracle when making big changes to a World environment.

Q9: Is indirect access (via a third-party system) something to worry about with JD Edwards?
A: Yes, albeit less infamous than with some other ERP systems (like SAP’s “indirect access” controversies). Oracle’s perspective is that if a third-party system or custom app is feeding data into or out of JD Edwards in a way that triggers JD Edwards processing on behalf of some user, that user might need a license. Example: A mobile app that allows a salesperson to query inventory from JD Edwards – Oracle would likely say each salesperson using that app should be a licensed JD Edwards user. Another example: If JD Edwards is integrated with an e-commerce site such that customer orders flow into JD Edwards automatically, Oracle might require licensing for some “users” representing that interface (sometimes handled via a module or a specific integration license). It’s a fuzzy area, but prudent practice is to assume indirect use = use. To be safe, you can create a generic “integration user account” in JD Edwards for each integrated system and then consider whether that should count as a user (usually yes). The number of actual end-users behind that integration is where it gets tricky. Consult your contract; some contracts explicitly mention interfaces or provide some allowances. If not, talk to Oracle about the specific scenario to get an official stance (or get expert advice) before an audit does.

Q10: How do I ensure compliance when customizing JD Edwards with new programs or reports?
A: When you customize JD Edwards (common for specific business needs), the main thing is to ensure those customizations don’t extend usage beyond what you’re licensed for. For example, suppose you create a custom report that pulls data from the Procurement and Manufacturing modules. In that case, you need licensed users for both modules for anyone running that report. Custom programs sometimes consolidate functionalities – always map them to the underlying JD Edwards modules and data they touch. Oracle will not care if it’s a standard or a custom screen – they care what data is accessed and by whom. Also, avoid the temptation to build custom solutions to circumvent licensing (e.g., writing a separate app to handle a process to avoid buying a JD Edwards module for it – if that app still reads/writes JD Edwards data in a way that mimics that module, you’re at risk). The best approach is to design customizations with licensing in mind: only use modules you have; for new functionality, weigh if it’s better to license the official module. Keep documentation of custom programs and which modules they interface with. In an audit, explaining “this custom payroll interface uses the HR module and we have enterprise HR licensing for all employees, so it’s covered” helps clarify things. In summary, customizations themselves don’t require separate licenses, but what they do can trigger the need for existing licenses to be in place.

Read more about our Oracle License Management Services.

Do you want to speak with us about our Oracle License Management Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit