JDE license information part 2

I'm going to document things to the best of my knowledge today about JDE licenses.  First of all, lets cover of the spelling.  In Australia, using license as a verb means you are going to use an S, but using licence as a noun (a thing - and when we refer to a JDE licence, that is a noun), so I should be using a c.

A good reminder of the above, is that I have a drivers licence in Australia - phew.

Oh, something else important.  Do not rely on this blog for a court case or legal advice.  Oracle will have a point of view that could be different to mine.  I've used 20 years of JDE experience and many oracle official documents and some unofficial communication to formulate my views expressed below.

Now, JDE licence in Australia, JDE license in US.  What constitutes one?

It gets complicated.

I have been told a number of times that if security allows you access to a program, then you need to have a licence for said program.  This is important, you CANNOT have "all doors open" security if you accept this as a valid definition of licence - as all of your users would need licences for all modules in JDE that are not explicitly secured out.

You can check your security using P00950 and make determinations from there.  Quite often if you need a licence audit done by oracle - ALL they can do is check the USER fields on transaction tables.  Oracle will divide transaction tables by there object librarian system code (F9860.SISY) and determine the module that you will need to be able to write records to that table.  ORacle will run some software that will basically select count(distinct(SDUSER)) from F4211 and say - you need X number of licences.  But, things are not that simple (they rarely are)...

What if you are getting new users and disabling users as a part of business as usual - what actually constitutes the need for a licence...  I mean, could I look at each and every day as a unique unit of time and find the number of unique user id's that have transacted against all JDE transnational tables in 42B

You can see from the above report that you are able to use.  You can find all tables in the Sales order management system code and select unique USER from all of these and add them together.  If we were using a timeframe, then you might also need to consider the UPMJ and UPMT fields to further refine the data to a list of users that have transacted.  This is ALL oracle can do.  There is nothing else available to track how many users are using the system.  

Of course, they are going to audit F0092 and F98OWSEC/ F98LPSEC to see how many enabled users there are too.  Note that if you enable LDAP or an SSO product like ours - myaccess (https://www.fusion5.com.au/jd-edwards/myaccess/), then you are going to reduce problems with lingering accounts.

If you have object identification enabled, that could also be used to farm data, but it's not easy.

So, at this stage...  If a user can sign in and is not secured out of a program, they need a valid license.  I'm told that there is a monthly calculation period for this.  But - F9312 for security history would need to be used and deletions would be hard to calculate...  Wowsers, things are getting really difficult, aren't they.  I believe oracle generally do not pursue this model and are more likely to run their audit software and get the transactional user counts, as I have indicated above.  

It's a little confusing and this contributes to confusion.  This allows people to think that only users that write to tables need a license (imagine that).  I don't honestly think that this is the intention of the licence agreement from oracle, I'm sure that if people are on the phones supporting the sales order processing in JDE, then they'd need a license for their inquiries.

If you are lucky enough to have an enterprise agreement - then report your yearly revenue figures and it's "All you can eat".

Remember there is also the concept of "IOT" licences, which can be purchased in groups of 50 at 1/10th of the price of a normal user.  This is designed for the situation that a device might raise a WO for itself based upon temperature excesses or something similar.  Therefore oracle would need to differentiate these in the data - very difficult again.

The Fusion5 approach is different.  We use ACTUAL JDE usage to build a report of what is being used.  We look at all application and report usage in the system and can give you a complete view of what is being used.  While you have an ERPInsights subscription, then this data is available to you at any time.  You can report on any day, week, month or year.  You can also look at your geographic regions to see what license requirements they have.  All of this data is exact.  It uses the actual definitions in JDE to tell you what you are using.

You can see from the above, we've used 2.2 million page views and summarised this by system code and then licensed module.  This is the usage from 1 Jan to 29 April for a single customer.  This is a birds eye view of exactly what is being used at the organisation.   You could slice and dice this by day or location if needed.

Our software costs $1500 a month to use.  It can automatically send you detailed reports on module usage on schedule so that you can be confident that your licencing is in check.  This is a small investment to prevent some large unintended costs.