IDEAS

JD Edwards requires a lot of Product Data (e.g. Item Master, Item Branch fields) to be populated when a product is created to allow the system to operate.

However, the developers of JDE have not provided for the fact that in a real business many of these fields need to be updated en-mass. For example, the Item Branch may include a Category Code for Master Planning Family - and due to a factory re-structure a list of 5,000 items may need to change F4102.PRP4 from 'M01' to M99'. There is no end-user way of doing this, and any database manipulation carries a sever risk of data corruption.

Given that any fields related to Product information (especially F4101 Item Master and F4102 Item Branch) may need to be updated en-mass for a specific list of items (usually prepared on a spreadsheet), I believe that JDE should have a feature developed which allows users to extract all Item Master/Item Branch table values they choose to a spreadsheet, make changes and re-load back into JDE. When this is reloaded from the grid, it should validate row-by-row using the same validations as if the data was being manually keyed.

Whilst there is a Z Table upload process, this is not usable for the end-user. Also, having this feature would be beneficial for new JDE implementations for initial data uploads and the subsequent corrections and refinements required.

Would there be interest in starting a UPK forum? I know there are already different social networking sites which host UPK discussions, but this would be the one with a distinct JDE/PS flavor.

Our company is on UPK 3.5.1,  and we am gearing up to use UPK to support our upcoming system upgrades. I know that I would love to hear how PS/JDE users are using UPK at their companies, and I'm betting that others would as well. Please hit me with your feedback.

It would be handy if JDE had a standard UBE that allows you to add UBE versions into the Processing Options so that when this UBE is generate, all it does is generate the multiple UBEs contained in the Processing Options.

The benefit is where a user has to run a couple of reports, updating UBEs etc at a stage in the process, but they can be done in parallel this saves them clicking to generate multiple UBEs.

I recently was looking for a way to find out Session Timeout'ed user's list in JDE server manager. But could not find any way to gather that information. All the Server Manager shows is Active users list on Web client.

Wouldnt it be nice to be able to tell which users were logged out of the system, what time it happened, what was the time of login etc.

Often times we get complain from the users saying that their session got timed out. But there is no way for an administrator to tell what was the real idle time for that user.

I would like to see a Quest Group formed for Oracle JD Edwards & PeopleSoft Business Partner Vendors specializing in World, EnterpriseOne, and PeopleSoft where in addition to finding them in the Solution and Service Provider Directory, we could generate discussion threads aimed towards them as a group.

Terry H. DeMoure
Business Systems Analyst
OYO Geospace
President, Houston Regional Users Group Oracle JDE/PeopleSoft Users, H.U.G.

JOBQs assigned at the version level are stored as part of the BLOB instead of as an accessible field in the F983051.  This makes review and documentation of jobq assignments on multiple versions at the same time impossible using a direct tool like either UTB or Databrowser.  Using BV for review of more than a couple of versions becomes time consuming, and updating them is a long tedious process.  Oracle should provide a UBE for reporting jobq assignments by version from the F983051 and for updating these attached jobq in groups.  The update should allow for either all versions attached to an object or a specified list of versions, or a Z table process to update multiple objects and versions in one pass. 

Enhance JDE to permanently record the user who approved a batch for posting and the user that posted the batch (i.e., ran the R09801) for the batch.  This would need to allow for multiple postings for voids, added transaction lines, etc.

We are not able to prove to our auditors that we followed company policy which requires an appropriate person to review a batch before it is posted to the general ledger.  The closest way we have to do this is to dig out the paper documentation of a batch.  We are trying to move away from having journal entries received electronically, printed, signed and then scanned to be stored electronically.  If JDE would track who approved an F0911 record for posting, that would eliminate the need for us to print all of our journal entries.  It would also allow us to prepare a report for our auditors to show them who approved each line for posting.

For example, if Tom enters a transaction, Dick approves the transaction for posting and Harry runs the posting job, Tom is recorded to be the originator (GLTORG) and Harry is recorded as having updated the record (GLUSER) temporarily.  There is no record that Dick approved the record to be posted.  Also, if a later process updates the record (e.g., an account reconciliation) the GLUSER is changed and the record of Harry having posted the batch is gone.

Surveys show that COLLABORATE attendees want more information on Project Management. As we look for speakers for COLLABORATE 12 in Las Vegas, we want to know what you need. What ideas do you have about project management? What information would make managing your projects more streamlined?

It would be great if there was an additional free form text field for PDBAs that allowed the users to make notes about the particular PDBA.....like the purpose of the PDBA, or why the PDBA ended, etc.

It would be handy if JDE had a standard UBE that allows you to add UBE versions into the Processing Options so that when this UBE is generate, all it does is generate the multiple UBEs contained in the Processing Options.

The benefit is where a user has to run a couple of reports, updating UBEs etc at a stage in the process, but they can be done in parallel this saves them clicking to generate multiple UBEs.