Frideas! - 4/18/2025

Frideas
Designed by Freepik.com

On Friday, it’s EpiUsers Frideas Day! Have you been to the Epicor Ideas Portal recently? If so, are there some ideas you want to encourage other users to vote for? Maybe want to add comments to an existing idea?

2 Likes

Missing: Field Help. Last seen in classic. Reward: Sanity.
~ on @aosemwengie1’s behalf… and EVERYBODY’S benefit!

10 Likes

Not mine but from (I am assuming the same) @jeffbrus :

Capture full ship to address on Order, Shipments and Invoices

Ever tried to make a BAQ of invoices and where they shipped to? So fun. And also, it’s a lie because addresses change…

6 Likes

Kudos for the use of the term labyrinthian! This may get my vote on that fact alone. :rofl:

3 Likes

I was proud of myself for spelling it right on the first try! Not a word I use much.

5 Likes

Speaking as an insufferable data normalization fanboi, keeping a static copy of the ship-to detail for every shipment is totally the right thing to do.

Not in all three places though. It’s a shipment, one copy with the shipment does the job.

A database developer who hasn’t been around shipping might think, “why not make ship-to immutable and add a new record with each ship-to change?”. When you get down to it, every shipment is a heap of like 12 things you’ll find a list of “falsehoods programmers believe about …” for, plus arbitrary instructions and other random junk. Storing a snapshot of each shipment is good and fine.

7 Likes

@timshuwy

Note to self: if I make one or more UD fields for this, x(16000) will not be big enough…

We got burned with Sales Tax reporting because users would just change the ShipTos when a customer moved locations… Had to create BPMs that would block changing the ShipTo after it was referenced on a shipment/invoice, etc.

2 Likes

ShipHead.LabelComment nvarchar(max), ShipHead.ShipComment nvarchar(max), ShipDtl.ShipComment nvarchar(max)

richard dreyfuss jaws GIF

1 Like

We need a thread/wiki on here of “Things I Wish I Could Tell Myself Eight Years Ago Before We Went Live on Epicor.”

  • Don’t use separate UOM classes; just throw them all in one so you have any hope of converting later
  • Don’t use Phantom BOM ever; just do non-stock instead (I know; people disagree)
  • Make a BPM to record the addresses on shipments and invoices (accordingly)
  • …and so on
5 Likes
3 Likes

Great minds . . . Move bpm code to function maintenance and keep in classic aka power tools

3 Likes

Kinetic grids should always have the filters on by default unless personalized to be off

This is an idea that Epicor has marked as in development for 2025.1. However the functionality delivered in 2025.1 is the exact OPPOSITE of what was suggested in this idea. Very disappointing.

4 Likes

See how many more clicks it is to try to find the thing in 2025.1? This isn’t a step backwards, its a catapult backwards.

1 Like

The weirder thing is that pre-2025.1, filters are always on! They behave as if hidden or not hidden.

If you filter a column in 2024.x, then disable filtering on the entire grid, your filtering is silently retained. Disabling filtering hides filters, rather than disabling filtering.

The one nice thing about the 2025.1 method is, it at least appears to eliminate that misleading behavior.

4 Likes

agree that this looks like we have not added field help, but we actually did. We have an interesting challenge, and here it is:

  1. in the SMART client, the field help was actually stored in the CLIENT. therefore, on each client screen, you could get differing help depending on what was loaded into that individual client… so field help for the PART field in Order Entry could be different than in Part Entry, Quote Entry, Job Entry, etc.
  2. We didnt find this out until after we moved to the browser, and foudn that field help was blank. Once diagnosed, we realized what had happened.
  3. BUT when we moved to the browser, there is no “client” that can have this data. we really wanted to have ONE SINGLE source of truth.
  4. we had to do a big data migration from all the individual client help fields and push it into a single database on the server, updating thousands of fields with help data from those 1000s of fields in the smart client… deduping data, etc.

in some cases, we may have missed moving the correct help data. At this point, we dont need to “bring back” field help… we have already done this. but what we DO need to do is properly populate this field help on the server in places that we missed.
If you could, please create cases for those that we obviously missed. This should cause a review of other places as well (we do NOT want one new case for every missing help record) ;-)… so if you could create a case with some examples, it would help to resolve this issue.

4 Likes

So when support rejects it and say to make an Idea… then what? I’ll make a case but I’m sure it’ll get rejected.

3 Likes

I have reported this many times. Rejected every time.

5 Likes

CS0004885916 created for the missing data in Kinetic field help.

1 Like