PRUKID field of F43121 Table is populated with all zero

Hello,

Could somebody check if F43121.PRUKID is populated in your installation. In our installation ( JDE E1) it is populated with all 0 and I am having hard time to find out the cause of it. Any suggestion highly appreciated.

It's all zeroes in 8.10. Despite its name, it not a key field. Maybe it's obsolete?

Thanks Janice, I figured that could be. Then again, ILUKID in F4111 is populated correctly. What I am really after is the Primary key of F43121, which is not updated by JDE. In F43121, PRMATC is part of the primary Key but is updated by JDE. I am trying to build a data warehouse out of JDE Data. Things like this making it a nightmare. Very poor standards in DB Design and data quality in comparison to other ERP systems.

Ok If you are going to criticize JDE then this is not the forum because there lot of passionate people like me who go through the posts here.

I think you are in the E1 version of the software that would mean the primary key will be in F43121_1.It seems there is an AS/400 class in Feb. which you should attend and also before even attempting to pull data from JDE for a Data warehouse burn midnight oil for 10 years then you will take back your comments. The data is not normalized in JDE but that is for a reason. I am not saying everything is good in JDE and I have had the opportunity to compare Oracle, JDE and SAP for an organization and they all have their Plus and minus. It also depends on the company how they are using this software. By the look of it JDE is next best selling software to SAP. I am sure Ed will be banging his head on the wall for selling JDE to PSFT so cheap. Anyway coming back to your post, please mention the version of the software you are working on and if you do not know that then there will be someone called a CNC person and ask him.Thanks

A forum on a software suite in which one may not criticise the software is spectacularly unhelpful - I don't believe this is that forum.

A database based system that requires you to spend 10 years working on it before you can extract data from it is spectacularly useless - I don't believe JDE is that system.

One can be passionate about something and still see the faults.

online,

your statement "JDE is next best selling software to SAP" really surprised me. My understanding is that though some JDE sales are occurring, Oracle steers new customers to E-Business suite.
So do you have some articles or other sources regarding a resurgence in JDE sales? I'd love to see that if true.

Thanks,

This nonsense has come up before on these forums: Don't bash JDE. But if we're not able to speak to the faults of the software, then how would we ever get Oracle to make improvements? Frankly, if the software were perfect there would be little need for these forums.

I work with JDE, and there are lots of things I like about it and lots of things I don't. But don't try to tell me that I can't speak my mind about the software, good or bad. Otherwise, this isn't a forum, it's a fanboy site.

Personally, I haven't been at this for 10 years but I'm still able to pull data from JDE on our AS/400 without a problem.

And please enlighten us: Exactly why isn't the data in JDE normalized? What is the reason you cite? I had a JDE executive in Denver tell me that the data in JDE IS normalized. But I've seen the data, so I didn't believe him . . .

With all due respect Mr Online, I have been designing and building data warehouses for last 12 years. Out of which last 4 years in JDE. Yes, I have built a BI system using JDE data, that is used by 3500 users world wide. I am very familiar with all major transaction tables F0911, F0902, F4211, F03B11, F0411, F4111 , F4311 and F43121 etc . The reason I said, JDE has poor design standards is because there are number of places they have violated best design practices and data quality standards. I mean, who builds a transaction table like F4111 without an UPMJ column? And which ERP system updates the natural primary key of a transaction table like F43121?

You can defend JDE as much as you want. But coming from a data architect and DBA back ground, I am not afraid to say it the way it is.

Peace!

I am compelled to agree with Mr. BI...one of the places that the design inconsistency has hit me is in the nexus between the F0411 and F4311 tables. About 15 years ago, I was looking to create a report in World that could link these tables by the DOC (document number) field. To my chagrin, I found that one of these fiels was numeric, and one was packed...as a result, I was able to create the report, but had to use DIGITS (remember that?) to do it. Now, if I want to create the same type of report in E8.11 all these years later I have to use...DIGITS.

Yes, DIGITS has been my best friend in other places as well...this would not be the case if the left handed programmer working on A/P talked to the right handed programmer working on Procurement, or if a third party watched the continuity between tables.

Now if anyone has seen my previous posts here or heard me at FOCUS, they would know that I am an unabashed fan of JDE, just short of being a shill. That does not mean that there are things that could be improved. At this point NO ONE has the perfect ERP package; it is only through the ability to cite faults and have same remediated that you end up with a software that is usable now and in the future. Places like this are the "grass roots" locations where constant improvement can start. As long as we open the can of "constructive criticism", I don't think even the engineers at Oracle would mind.

Part of the function of JDEList has been to identify problems with JDE (and other products) and provide solutions and work arounds to allow users to do what they need to do. This is the value of this forum. Therefore part of the reason JDEList exists and is such a valuable resource is that faults exist in JDE. Rather than complaining about problems, just for the sake of making a complaint, a positive angle on problems is valuable. The positive angle involves work arounds and solutions that have been developed by users and also an effort to get the Software Vendor to fix problems.

That's my AUD 0.02 worth.