As we have moved from the “Go Live” event to normal day to day use, the amount of BAQs, Dashboards, customizations, etc… requests have been coming in at a more frequent pace.
Before we go too far down the road to completing these requests, I thought I would ask what you have learned works and what to steer away from for naming conventions.
I would like to create some type of standardization so that supporting the different development areas will be less messy.
I’m the only one in the company that does customizations, BAQ’s Reports, etc… So I have the advantage not having to us a system that will be maintained by several different people.
End edit
Some conventions I use:
Using my initials as a prefix on the BAQ’s id. For Example: CK-ShippingSchedule
Using the BAQ’s ID as the ID for the dashboard or report. Example:
Dashboard ID CK-ShippingSchedule uses BAQ ID CK-ShippingSchedule
BAQ Report ID CK-ShippingSchedule uses BAQ ID CK-ShippingSchedule
if variations of the dashboard or report are required (but still use the same BAQ), I’ll append a numerical suffix. Ex: Dashboard ID CK-ShippingSchedule_2 is the second dashboard that uses BAQ ID CK-ShippingSchedule
For customizations, I assign an ID with initials for the Form, with a version number after it. Example: SOE_03 is the 3rd version of a Sales Order Entry customization.
I include the Customization ID in the forms title bar. The Part Maintenance form’s title is 'Part Maintenance (PM_02)`
I also include the Customization ID in the menu entry
I tend to think of Id’s as a reference like a variable in programming, so I instinctively uses underscores (_) instead of dashes(-) as separators in an ID. But Epicor isn’t consistent when sorting these. I try to only uses dashes now.
I have BAQ’s that Begin with CK_COS... and others that begin with CK-COS... When using the search button to load one, the way you perform the search determines where they fall:
With the search setup to return a max of 100, Query Id starts with: CK, the search returns the first 100 records. And the ID’s starting with CK_ aren’t included in the first 100 records.
After hitting Next 100, (there are only 173 that start with CK), all 173 records are shown, but the ones with the underscore are at the top.
With the search setup to return a max of 200 records, all are returned, but the ones with the Underscore appear at the end.
Keep in mind BAQ ID limit is 30 characters, Dashboard ID is 20, and BAQ Report ID is 15. 
YIKES!!! Did not consider that!
Neither did they 
Hi Doug,
Our BAQs are a mess. At least they’re marked with Author so can see who has the worst!
My recommendation is in the area of customization naming. You will likely need to occasionally provide a new revision of customization that you will have developed in a test database. When you go to deploy, unless you call it the same name, you will need to go through every place in tree structure to assign customization. This is a real PIA IMO 
So I recommend you always call your customizations the same thing, regardless of revision. Maybe SalesOrderEntry_Cust or something. Mark the revision info elsewhere, maybe comment area of code with date/initials, perhaps on the interface itself (e.g. Rev. 1 on order header tab) etc. This has saved us many headaches.
Nancy
In addition to consistent naming practices listed by others
I also tend to add BAQ’s/Dashboards to save time search/list custom entities and their related components. Things I can use to save time whenever I need to go back and figure out where/how something was used.
A few examples…
search/list BAQs AND include “where used” for both dashboard/BAQR
( And for any BAQ/Dashboard used in customization via DynamicQuery or Sheet Wizard,
I’ll always try to add some note to the description fields).
custom report style listing with any details, BAQs, RDDs, etc…
an indented menu where I can filter by the contents of field “arguments” or “program”
Key is be consistent with whatever you pick but this is what I do.
Use camel case for naming, avoid underscores and hyphens. Both require a pinky stretch to type and don’t add much in the way of readability if mixed camel case is used. First letter of each word is capitalized.
Use descriptive words as much as possible, I have even forgotten what some weird abbreviation I used means. For Work in Progress I might put my initials on something but the final product is just a descriptive name. For customization if you change the name for each release the user will lose their personalization. Unless a customization has a special purpose I usually use some form of the original form name. During work in progress I will add a -001 incrementing for each version until I am done so I can roll back if I need to, breaking my rule about hyphens but I don’t leave it when I release.
For user defined fields I usually use a two or three letter abbreviation for the company so for AT&T the field name might be attPhoneNumber_c. Epicor forces the underscore c. This way all UD fields group together. Other like it without the prefix.
For all my stuff (like @ckrusen I’m the only one editing really) I like to use 3 letters for the company as a prefix for everything that goes into production. Luckily mine starts with ‘A’ so all my custom production-released stuff goes to the top of the list. Everything in Dev has ‘test’ at the end and is removed when released. When I export things like dashboards, the output file will contain “_wBAQs” at the end if I export with the BAQ’s. Same principle with UI, custom searches, etc… It makes everything easy to identify in the searches (and exports), plus it does not’ contain any other ‘logic’ that I have to remember to keep up with.
There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton
I stopped doing that because the _c is enough. Same for RDDs I just name my RDDs JobTrav_c for example if I clone the system one.
Over time I have created a Patterns and Practices document and it has evolved. Its idea is to identify all the different customisation scenarios and put some of standardisation/process around them, for example Comments in RDLs, version numbering, custom code comments templates, using the Dashboard Notes etc…
Initially I was highly interested in making sure I knew who did what, we had a mix of Epicor consultants, CSG and myself doing things. CSG all of the time (er…well most of time) label anything they added as csgxxx so extending on the CSG thought I have done the following.
In house derived - Company first three letters plus and underscore XXX_
Epicor Consultant Derived XXXEpi_
Like @hkeric.wci I started to go down the same route with custom fields but realised that the _c is enough and no more CSG customisations were being done anyway.
For the most part it is has worked, but as I have engaged with different people over time things have developed. From time to time you need to remind people to follow the process, but that’s human nature I suppose.
We did have one incident where a consultant started using CSG as the prefix which did cause some confusion.
I like @MikeGross point on the [quote=“MikeGross, post:9, topic:68638”]
“_wBAQs”
[/quote]
I’ll steal that one if you don’t mind.
One small thing we like to do is add an indicator into the name that tags which “epoch” the object was created during. For us those epochs are E9, 10.1, and 10.2. Over time this will hopefully become less important as we embrace DevOps / become more agile / upgrade more frequently, but if you have historically followed the “Waterfall” approach in your upgrades it can be very useful to know when an object came about with a quick glance at its name.
For example for my BAQs, I just started prefixing their purpose.
What prefixing them for their purposed allowed me to do, is upgrade major versions faster. I can easily just Search for QS- and tell you all BAQs related to some type of Quick Search - or - a BAQ that is used in Code etc.
And if the same BAQ would be used on a Dashboard and Report? You make two identical BAQ’s one with the DB prefix and the other with the BR?
Usually yes because if I ever need to lets say add a column to 1 or some weird request, I can be assured that I wont break the other one.
Remember that the tooling is made of Business Objects as well so we can create a BPM to enforce naming conventions if we want to be strict about it.
And one-off errors.
My “Standard” has evolved over time… My latest standard for naming BAQ/Dashboards is as follows… lets take the idea that I am making a Job Batching Dashboard, and it is going to have three BAQs and one dashboard:… I come up with a prefix that will unify all of them.
Example 1: Job Batching Dashboard:
Dashboard Name & Description:.
BAQ Names and Descriptions:
So… the key for me is to have all the components of the dashboard start with the same pre-defined prefix. This makes it easy to find later when you are editing it.
Example 2: Sales Backlog Dashboard
Dashboard Name & Description:.
BAQ Names and Descriptions:
Mine is similar but I do also start them all with DB-JBD_Jobs, DB-JBD_Parts for example. But yes similar.