There have been many ideas entered around this problem but it still remains unresolved. This one is even marked delivered but its definitely not been delivered. https://epicor.ideas.aha.io/ideas/KNTC-I-3017
In my latest frustration, I attempted to find the auto receive checkbox in Kinetic Job Entry. The field help is completely blank. Meanwhile all the information I actually needed is back in classic. How can I move to the browser when I have to revert back to classic to find any information?
In case anybody doesn’t believe me. Field help in classic:
Note that the DB field reference in the technical details is blank, so I can’t check to see if there is more information in the data dictionary either.
Note that when you search autoreceive in the help, there are ZERO results returned.
This thread is not about the autoreceive checkbox. I have the information I need.
This thread is about the fact that the functionality in Kinetic is severely lacking as compared to what we have in classic and it needs to be resolved if we are expected to move to the browser.
This is not a one-off. There are many many many other places where I run into the same thing. This is just the most recent example that wasted valuable time out of my day and given me second thoughts about attempting to move my users to the browser. Epicor has said for years they are “working on” moving the classic field help. I have not seen any improvement.
This is one that seriously needs to be addressed and shouldn’t be taking this long…but hey at least in 2025.1 the material complete icon in Job Entry will now be green instead of yellow!
The field help functionality is baked into the form as other previously have mentioned. However the actual data is in the FieldHelp folder on the application help website… Stored as XML files. The Field help in the classic screen passes over two pieces of information, the panel reference and the guid of the object when you click on it… when you initially open the field help it passes through the filename of the assembly that is running the form, there is an xml file with the same name in the field help folder, clicking on any object in the panel on the screen sends the guid of the object (as mentioned Previously) to find the key in the xml file.
Anyway that’s how I understand it… Interestingly there is a BuldFieldHelpForDocPanel method as well, which I think might be a hang over from the old “Annotate Help” functionality that fell off the perch a while ago.
So to get the missing information into the kinetic help we need to make some conversion tool to populate the Business Description in the Kinetic Field help…
When you go to the help file on the browser -
Under Job Entry it list the various cards and fields on each card.
For Auto Receiving - here’s the help.
** Auto Receive - Indicates whether labor or receipt transactions against this operation will create automatic receipts to inventory. If you use this feature, this receipt updates the quantity on hand on the part record. The process is triggered when you post labor quantities against this operation that exceed the quantities required for the sales order. This checkbox is automatically selected if the job is created as part of a project. As a result, the job does not have to be opened for the purpose of closing this operation.Normally, you will select this check box for the last operation on the assembly or the final assembly. Parts are received to inventory at the current unit cost, based on the part costing method (average, standard or last).*
For example, you enter job 12345 to make Widgets, linked to a sales order quantity of 75 and an additional stock quantity of 25. The last operation is selected for Auto Receive. If you report a labor quantity of 110 pieces against that operation, 35 pieces are received to inventory. This is calculated by subtracting the sales order’s 75 quantity from the 110 quantity that was manufactured through the operation.
The following rules apply:
You cannot use the Auto Receive function on an intersite job. If you attempt to select the check box on such a job, an error message displays.*
This check box is not available on service jobs, or if the Track Multiple UOMs check box is selected in the Part app on the record for the manufactured part.*
You can automatically receive to stock a serial-tracked part on any job operation.*
If legal numbers are used for the transaction type and a legal number has not been assigned, the legal number automatically generates during the auto receive process. The process first looks for the first active legal number configuration (alphabetically) that has a generation type of Automatic and has a selected WIP to WIP or WIP to Stock Transaction Document Type marked as System Default for the transaction type. If the process cannot locate a legal number configuration that meets the first set of criteria, the process looks for the first active legal number configuration (alphabetically) that has a Generation Type of Automatic and has a selected WIP to WIP or WIP to Stock transaction document type. If the process cannot locate an active, automatically generated legal number configuration number for a WIP to WIP or WIP to Stock transaction document type, no legal number is generated.*
So in 2023.2 they did deliver the new functional aspects for delivering this info to the Kinetic UI. It now lives in the IceCommonDB in a table called FieldHelp. Checking this specific field you refer to reveals that it hasn’t been ported into this table, and the same is definitely true for many many other fields.
Seems a fairly trivial piece of work for Epicor to do now to compile the old data and insert it into the new DB table - the wiring up work is already done!
Field help is something we are continuously working on and there are a lot of back end reasons we were not able to completely uplift the experience directly from the classic environments. We are actively working to improve those fields that are most used, but please always feel free to submit an Epicor Idea if there is an area you would like us to consider closer. We are also working on additional features for future reason that will give you more capabilities in managing your companies field help experience.
We need ALL of the classic field help in kinetic, full stop. It would be different if searching the name of a given field in the kinetic application help yielded any relevant information, but 99% of the time there are no results at all.
The field help is what makes Epicor usable. There are so. many. fields. And so many minute and quirky details. We must have the field help. Its not fair to expect that we open a separate idea every time we find something missing. I am finding that there is still a vast amount of the help that is still missing even though epicor considers this resolved and closed the idea about it.
Perhaps regular updates as to the progress in the release notes would be a useful way of communicating the progress.
With that being said, based on what information we have discovered is it just seems to need a bit of dedicated effort to complete this task rather than having it flap out in the breeze for so long. All the information there in the XML help files. I understand there are priorities.
On another minor point it would be very helpful to get the help annotations back. That was a very helpful way to add in company specific help additions.
I’m also finding that some of the field help appears to be wildly out of context in kinetic. In other words, its there, but its like it got copied from a totally different screen just based on the field name with no regard for which screen the field is being displayed in. Just one example. Here is the field help on the supplier field in Approved Supplier Maintenance in classic:
Yes! It should be as simple as making sure each DB field has field help mapped. Yes or No, and get a % complete status for each version. Heck, this could be updated for dot releases. Make getting to 100% a corporate goal for the “Lets Fix Epicor Release With No New Features”. This seriously should be done for 2026.1 if classic will be sunset.
We do something similar for migrating users from Classic to Kinetic - Get a list of forms, migration status, and know your % for progress…
Users should not have to spend 10 minutes each time to submit Ideas tickets for every field help that is missing. Epicor already knows which fields aren’t set.
Can Telemetry show what field help is being searched that doesn’t have content? This could help prioritize…
Ultimately, we’re trying to teach our children users how to become independent and help themselves. If field help is empty, it creates more work for all Epicor customers to answer internal questions when it’s been answered before in Classic. Let’s not lose the good knowledge that’s there.
If you’ve got a field in a database, there should be an explanation for its existence. If it’s a calculated extended value, tell us how the number was arrived at. If it’s a placeholder field for future development, just say so. Don’t make us guess. Wouldn’t the time invested in documenting the tables/fields likely lead to a measurable reduction in support calls?
The most annoying part of this is that the field help is all there in the xml files if you install the on-prem help. So all they need to do is reverse engineer it a bit and then “Copy” to the FieldHelp Table in the Ice.common db. I just tested this and that table does exactly what it says on the box… It might be as simple as parsing the xml files and turning them into TSQL statements…I am pretty sure all the field information is in the xml… Might be a fun project.
