Good morning,
How do you all keep track of your BAQ library? I’m just crossing over 300 BAQs, and I know I have some that are junk, some are duplicates, and some are actually useful. Honestly, I have no organization method. I make up a name and try to document it in an email if I end up sending the data to anyone. That way I can search for the email and figure out what the BAQ was. I also export my BAQs so I have a list of them as a backup locally.
I am considering way to make this process more sustainable. Do I make a spreadsheet that lists each BAQ, what it does and why you would use it? Yeah, I always default to a spreadsheet… shoot me.
what I have done is created an Excel spreadsheet pulling a list of all the BAQs directly from the DB, that way I can add as many notes as need to keep track of all of them. Not sure if it’s the best option but works for me.
At least in 2024.1+, the Classic Screen for BAQ has a comment section and a Where Used to identify Dashboards, Quicksearches, BAQ reports, etc., but not REST or Code Widgets.
I do use that comments field sometimes. I often make BAQs for API calls into Excel (Thanks Clint!)
I like the idea of using security codes to help identify quick BAQs to dump. Has anyone else taken that approach?
I was hoping someone on here has their stuff together and would share their prefect professional process.
Excel never heard of it?
I have at last count 715 BAQs.
I assign a prefix and 3 digit running number.
QM Quote Management, OM order Management, JM Job Management, etc.
Example:
BAQ = JM031
Description = “JM031 - Open Jobs” and try to have key words for searching like, Labor, WIP, Costing, etc.
Could be a Report, Dashboard, or Quick Search (Or maybe all 3)
It’s nice when some one has an issue all they need to reference is “JM031”.
Also nice for work instructions. Run JM031, OM023 and JC089.
I throw everything in github with descriptive descriptions. Each time a baq is updated I export the baq file and upload it into source control. This helps see what baqs are modified frequently, and which are stale.
at some point I was about to do a clean-up and do the same, but we have about 3,438 BAQ’s across 34 companies, used in many dashboards and reports; at this point I have no idea what to do if leave it as it is or do a clean up; I have also this problem:
I later releases they added a last change date field. This may help. You should initial and date the description field and un share the garbage ones. Then after a period of time delete them.
we are even evaluating to re-implement; that way we can clean up a lot of data that is not used anymore, customers, suppliers, parts, BAQs, Dashboards, Customs, etc etc
Ok in the absence of source control these are the steps that I use. It only works if you are disciplined.
Firstly I always use a standard prefix that identifies the BAQ as unique to being made by you or your team.
Second I use the comments as a running commentary of change including
Date, who and version. And for Pete’s sake (sorry Pete whoever you may be) Make the comments makes sense and readable by the next person. No point it only making sense to you.
Some people would argue not to put your name on your work…I disagree. Two points come to mind. If whoever is working on it needs a bit more tacit knowledge then it may be possible to reach out to the author. It also provides a communication channel if for some reason you totally ballsed it up, and the next person is kind enough to provide some constructive feedback, they can. There may even be a new and better way, that they can share.
The version I include in the description of the BAQ.
The base or master BAQ has the Prefix_BAQID with no version number included in the BAQID. I put the version number on the description. This is important if you have any objects using the base BAQ, you don’t have to go and update them as well (perhaps dashboards any added columns in the baq sometimes don’t show, although today that was not the case in 2023.2)
Two ways of maintaining a way back to your latest version. Is make a backup copy of your base (including the version number as a suffix in the baqid to make it unique) once your happy at sometime in the future you can ditch all old versions. You can even leave the shared flag disabled and nobody will be able to run it other than the author. This gives you a handy way to go back to an earlier version if you need to, just delete the base, copy the previous version to base.
Or
Use a source control tool like Github to store your baqs and export them, and check them into your repository. If your are not familiar with Github then using Github desktop is a handy way to get things into your repository. You can do this for most things in Kinetic, but it’s a bit of a manual process. and @klincecum s awesome export all things tool may be handy in this situation also. What you won’t get for some of them is to inspect the contents. You can only inspect the contents and diffs if the files are text, and we know some exported objects in kinetic are not. It will still store them in github
That’s how I do it, it may be a bit clunky, but it’s saved me a few times.
You just make the repo private. Apparently it is possible to create your own remote repos without using Github. I have never done this but that’s what the engineers handbook just told me. You could even use one of the many Git Server docker images to act as your git server.
There was someone on here who was working on some git integration with Epicor… Similar along the lines to @klincecum s export all things… Can I find the post… Of course not.
if leave it as it is or do a clean up; I have also this problem:
