custom request

[adeel]

Hello there

We get lots of request from users to create .net applications e.g reports/applications e.g. to create bank file - account payable/ payroll file etc or click once application for reporting.

I strongly believe that JDE already have desired layout within JDE and Bi publisher for reporting.

Just wondering how you provide solution to your users (Custom or stick with JDE ). Is JDE has lacking?

 

[rsvconsulting]

Users always want something they in most cases do not need from a custom application that they can easily obtain from JDE. Please carefully evaluate every request and do your best at due diligence tyo show it can be created and delivered by JDE out of the box vanilla. I always thoroughly vet the user(s) requirement so that I can fully understand the need, get them to sign off on the requirement, then I determine the true value add to the Enterprise so that I can prioritize the request, and then I demo how JDE can deliver it and to what % it hits the agreed target. A proof of concept in JDE works wonders!!

 

[adeel]

Yes.
I know companies they do zero development out of JDE. This is ideal way because they dont need to worry on upgrade time to change new server connection etc. Also no need to maintain source control on TFS or other version control.

customization in RDA and FDA within JDE is also hassle during upgrade as you need to retrofit the code.
I guess that's the preferred way for some of us. That way everything within JDE.
Thanks for responding.

 

[Rauf]

The issue with most of the users is that they compare JDE with other tiny softwares, which might boast for user friendliness.

In our environment, we most of the time end up with a kind of fighting to agree upon the requirement.

As the business user says, the ERP should be business driven. So we impossed to customise HR/ Payroll (about 80%). And no way to upgrade to latest version because we cannot do retrofitting for thousands of objects.

 

[adeel]

Thanks
I am not sure but I guess you have to pay some fees to keep the old version of JD Edwards to get ESU etc.

The whole issue I guess that Oracle provided the FDA and RDA without knowing how fast the technology changing to keep ERP as web standard and the other side their clients keep doing customization which is now a hassle to upgrade.
Thanks

 

[brandonkirsch]

The JDE Toolset is a true pain for reporting, for several reasons.

There are huge performance penalties built into the very core of the software. You simply can't make efficient use of the database for many common usage scenarios.

Reporting is one of those things that don't fit very well into the DEV / PY / Production lifecycle, either.

People are reluctant to ask a developer to make what may be an extremely simple change, only to have it queued up waiting for an IT resource to do the work and then having to wait several days for the promotion.

Most alternatives have their own set of drawbacks as well. But they should be explored. Based on the fact I've never seen a truly great reporting solution, I would recommend that you stick to the cheap options.

Even then, you will always be trying to balance the work.

 

[DBohner-(db)]

Anyone that looks at JDE / E1 as being archaic, a resource hawg or a bit of a dinosaur - it's time to roll-up the cuffs and have a few words?....

Turn on Debugger, grab JDETrace and see what is really happening behind the UBE/Application (then try to have your .NET developer match that automation). There is so much happening behind the scenes, we oversimplify what is happening in the engine. If you had to replicate all that 'stuff' in .NET - your development cycle wouldn't be three-days-to-Production, it would be more like 'looking for a new job'....

btw - Boise is nice this time of year (every time of year, actually)....

(db)

 

[jdelisths]

"your development cycle wouldn't be three-days-to-Production, it would be more like 'looking for a new job'"

While I agree with this comment, there a a LOT of things you can do in .NET (or any other modern programming language for that matter) that you simply cannot do in JDE. Tracing and logging in .NET? Just grab an open source component, a Nuget package and you are set to go.

 

[adeel]

Well there are lots of good comments.

What I feel is that if you have a good business/functional team who knows JDE well, your chances that you will have less customization instead of sending request to developers for customization within JDE or in .NET).

JDE developers required lots of experience to customize objects and other side .NET is simple and huge community for developers to get reference.
Reporting is not fancy in JDE and you can see many reporting tool outside for JDE (I never see for any other ERP system). Reportsnow and insightsoftware as an e.g).

Thanks everyone!

 

[Chan Rana]

We use data warehouse for all the adhoc reporting which are mix of JDE & other systems. So DW can be an intermediate and quicker solution. Offcourse you will need to buy and have some skills set for it.
I would recommend to use the skills set you already have inhouse rather looking for a new other then JDE.

Chan

 

[adeel]

Hi Chan

I hear you, Can you please tell what DW solution you use? but you still have to define data, data quality etc.

You can buy any JDE reporting tool which always have the external connection so you can use for other data sources as well.

 

[rsvconsulting]

You can also evaluate tools such as INSIGHT, which are relatively low cost and easy for end users to master.

 

[brandonkirsch]

If you had to replicate all that 'stuff' in .NET - your development cycle wouldn't be three-days-to-Production, it would be more like 'looking for a new job'....

There's no denying that JDE has a maddening amount of stuff going on underneath the hood... But JDE is consistently gimped by design decisions that were optimized for *ancient* database platforms, and we are all still paying the price for it.

Just look at all the cruft in there, right-justified MCU fields that saved precious CPU cycles in 1985 but have destroyed efficiency ever since. Weighing in at a whopping 24 bytes with Unicode, one of the most common fields in JDE is extremely performance-averse.

JDE Julian dates, still terrorizing power users to this day, all because the AS400 won't store DATEs before 1940.

It's almost as if Oracle benefits by having such arcane designs that permeate every layer of the architecture.

 

[Larry_Jones]

...It's almost as if Oracle benefits by having such arcane designs that permeate every layer of the architecture.

Its almost as if Oracle has taken a page from SAP's playbook