So, quick question. There are several tax fields that can be set at the shipment level IIRC. If that is set at shipment time, won’t we get a much more accurate report than going through the error-prone BAQ trying to recreate ship to information? Even if done correctly, isn’t there still issues with freight forwarders?
1 Like
So, all valid points for tax reporting. I think your point is that taxes and regions and everything changes over time anyway.
But to take a cop out approach, I just know that accountants have asked a few times over the last couple years for the ship-to addresses for all invoices in X time span.
Yes, it’s often because of taxes that they ask for these reports. But people always want supporting documentation. I can’t exactly say no.
2 Likes
Hello Tim,
I thought I had posted on this previously, from my research, I found that the classic field help was locked up in xml files from the actual help system. For example if I installed the help locally in an on prem install you could interrogate those files and see all of the descriptions, fields and related form and field guids.
Whilst we can see the information, without the source, from an end users side, there it little more that can be done.
I appreciate that it is a useful time for Epicor to revisit and refine the user help, and there appears to have been an “oops moment”. We are also well aware there are some incorrect or misleading descriptions that have been introduced over the years, that should be resolved. However it does seem that a talented Intern could have this problem (with the correct guidance) licked into shape pretty quickly. Making it an ideal learning opportunity.
My thoughts are this:
Iterate through all the source code capturing all the field guids, and epibindings.
Iterate through all the field help XML capture the field help information.
Lookup the related field in the ice.fieldhelp table, and if it does not exits, add it.
Record all the misses and then perform a verification, making potential amendments, perhaps with some Agentic AI tool that has come about as a biproduct (I was going to say Copart, but that might have confused things 
) of the Prisim development.
On behalf of the Epicor Users Community, I implore you to please make this a priority to get this issue resolved ASAP. Frankly this issue has gone on long enough and everyone’s credibility related to this issue is getting eroded.
How are we expected to ask our users to use the field help to help themselves if all it says is “Description is not available for this field”? Surely we all have plenty of other more important things to be doing rather than logging and answering tickets and Epicor Ideas, not to mention responding to them.
After rereading your post, I feel that the Epicor development team are in a better place to generate some sort of automated analysis on what fields need fixing when the “Description is not available for this field” prompt displays than anyone else and then fix it based on the information I mentioned earlier.
I hope you take this suggestion and thoughts as just that. By no means is this post meant to come across as an attack of any kind, just simple frustration. @moderators if you deem this post fit for deletion, then please do.
12 Likes
Yes! Surely there’s a way to query the db or UI to see when something doesn’t exist. Does Epicor really want hundreds or thousands of cases tying up EpiCare analysts? Imagine how much time that would cost Epicor’s customer base.
Say there’s 500 fields missing help. IT staff sends an all-hands email telling folks to report these. Users create an internal ticket to report them (10 minutes x 50 times x 2 people reporting each issue, since they don’t have visibility of the others)
10 x 50 x 2 = 1000 minutes so far
IT creates EpiCare cases: 10 minutes x 50 instances = 500 minutes
100 companies do this: 1000 + 500 = 1500 x 100 = 150,000 minutes
EpiCare analysts respond to the case, create PRB’s, initiate communication with DEV dept. 50 tickets * 100 companies * 10 minutes per case: 50 x 100 x 10 = 50,000 minutes.
We’re at 150,000 + 50,000 = 200,000 minutes, just in notifying Epicor via EpiCare.
Surely Epicor can identify missing fields. It doesn’t seem right to put this additional work on the customer base, unless it’s part of some promo - make a splash on who the top ten companies are with givaways or credit towards Insights or maintenance.
If not, how about a button in the Help UI to make it easy to report field help?
7 Likes
I dont believe that they will reject it… but if you pass back the case number, I will have it investigated too.
2 Likes
If you have the tax ids, how hard would it be to find all shipments with those tax ids and their associated addresses? 
I’ve had the accountants ask me for the same, but I can’t think of a single time it was not for tax purposes. Even for states that don’t charge a tax (looking at you Ohio), they want to know what was shipped in. We just created a tax code for 0%.
1 Like
I believe the address data used for Avalara is saved somewhere as you can see it in the “View Tax Connect Results”
1 Like
It’s saved in the avalara website and you can search transactions there. But as far as I know it isn’t queryable from within Epicor. Would love to be wrong.
3 Likes
In Avalara, as others have suggested? Or in Epicor?
Ditto.
On the other hand, there was a time we collected taxes and we were not on Avalara. I cannot see why we’d need tax/address info going back more than 2 years, but I don’t question it.
I do appreciate the alternative trains of thought. Accountants tend to be overly detail-obsessed, and I don’t always know what the real need is.
2 Likes
I think many users come to us with what to do rather than letting us find the best way to do what they need. 
4 Likes
Random related side thought… I see a lot of what I’d call “accidental” ERP admins and analysts turn up here and in similar communities. Someone gets tossed into a role without specialized experience or training because they’re smart or good with numbers or need something to do, begin to recognize the deep end they’ve been tossed in, finds epiusers, and flails a bit.
“Accidental DBA” and “accidental accountant” have turned into whole entire things with community maintained tutorial and reference paths, for similar reasons. I often feel something similar could be a community opportunity in the ERP world.
4 Likes
7 Likes
Who among us, honestly! It’s not as though there’s a whole labor segment wandering around with degrees in ERP administration.
7 Likes
I see a market opportunity for epiusers. Granting of honorary degrees in ERP administration.
7 Likes
Is that gonna be based off of leader board points or would it just be a certain patreon tier?
3 Likes
4 Likes
@klincecum you left off the seal
14 Likes
So here is the issue I logged:
In the context of job entry, this information makes no sense at all. Support’s response was:
“This is ‘Technical Information’ related to Vendor.VendorID which is pulled directly from the Supplier screen. The ‘Business Description’ tab at Field Help should be the one being reviewed when looking for the field’s Job Entry functionality.”
But the business description makes even less sense:
And on top of that, whenever I complain that the business description is blank, I am told to look on the technical tab. Are we now saying the business description SHOULD be populated?
CS0004886522
4 Likes
IMO both of them should be. The business description helps the enduser, technical details would be for advanced users, BAQ writers, tech support, etc.
4 Likes