• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

JDE User IDs

Hi,

I have a table in my data warehouse that is imported from our HR system that contains the following employee information:

  • Address Number (AN8)
  • Employee Name
  • Job Title
  • Manager Name

I want to relate this data to orders from F4211/F4201 based on the Order Taken By field (TKBY). To do that , I need to bridge the TKBY field to the employee address number (AN8).

My first thought was to join to F0101 on AN8, but while F0101 has the employee name, it doesn't have the User_ID field.

I've tried joining to F0092 on the USER field. This works for the majority of address numbers, but for some reason not all users have a record in F0092.

Is there a table that has the USER and AN8 field for every E1 user?

Thanks for your help!
 

DSauve

Legendary Poster
cholderfield,

The F0092 table IS the table that contains all currently-defined users in JDE. If you are finding employees who do not exist in the F0092, then perhaps they are old employees who have been deleted from your system? Also, if the TKBY field was edited, then that may cause a failed match in the F0092 table.
 

Larry_Jones

Legendary Poster
There's a couple of assumptions here in your statement:

1. You assume TKBY will always contain a valid JDE User ID. Actually while the out of the box system will default a JDE User ID to this field, User's may overwrite it with something else like JOES PIZZA.

2. You assume that your E1 CNC Admin is maintaining the User Address (Employee) number with a high attention to detail.

3. You assume that someone (HR?) is maintaining Address Book records for all employees. Being an old fart with a regrettable number of years of experience, I've found that in general, HR depts. are staffed with Liberal Arts majors that may have strong people skills but who are not all that good at attention to detail. In addition, does your organization use Temporary employees who are never assigned employee numbers?

Finally, as Don said, the F0902 table is the one you want.

Net,net there's nothing wrong with your approach - but bad data is bad data. You probably have to do clean up and possibly institute process changes to ensure that data is "good".
 

rsvconsulting

VIP Member
In addition to recognition of "bad data" I always try to develop a process and system response that works to minimize if not eliminate the "bad data" creation. So with that in mind I recommend that you visit the steps in the process and the system applications that capture the data and populate the data warehouse. With that blue print in hand you can identify the cause(s) of the "bad data" and create solutions to minimize or eliminate it.
 
Top