Naming consistency across Epicor suggestion

Feature Request
The feature I am requesting is a more coordinated and consistent methodolgy of naming conventions within Epicor.

Example of Issue
For example across WarehouseCode, I have seen…

  • WhseCode
  • WareHouseCode
  • WarehouseCode
  • WareHseCode

Multiply this by 3 as there are the same iterations using To and From as prefixes. Multiply this by the face that the warehouse description field takes the WarehouseCode variation then appends 4 different variations of Desc and Description.

Its not just this field its across the application, there is a like column that is used for cross referencing this to its original primary key. I get that, but surely you could just be consistent in naming the field that it is like to its actual name?

Not a massive issue, its just more challenging then it needs to be when building web based forms as the developer must identify and handle each variation of of this (Part, PartNum, PartNumber, partNumber)

While in principle I agree, playing devils advocate I think that much of this is legacy - many of the E10 table structures reflect embellished versions of the tables from Vantage including field names. Renaming these fields would make any migration harder, and potentially could see tens of fields requiring to be renamed and mapped in a given table to allow the migration to proceed.


@mcfreedombaby - Is this something that Epicor should clean up for E11, rather than attempting in E10? It would be really nice if there was a tool we could use to search within our customizations to find changed fields, rather than waiting for a failure during upgrade testing…

1 Like

I would expand that to UI consistency as well! The Dashboard vs BAQ forms not having same behavior is annoying!

Last used list from menu (OK in BAQ not existing in Dashboard )
Searching showing last save date ( Not existing in BAQ but exists in Dashboard)

Going from 9 to 10 was a big leap, and I understand those tools may have been created by different teams, but I maybe my expectations were too high… :wink:

I shall agree that such modifications (finding what can be improved in addition of implementing new features) can take some time… so hopefully for version 11 maybe?


Only Epicor can answer that one, my guess is that it will be based on version demographic.

To elaborate a little futher,

I understand the challenges of legacy versions and scale of the application, I don’t want this to be percieved as me complaining for the sake of complaining about something that cannot realistically be fixed(cost vs return). We all want more features, bug fixes and it done faster (and not pay more), dev’s do a great job at Epicor. They deserve credit.

I was hoping this could more be a request for a consolidated and consistant approach to new features.

1 Like