Our company implemented Epicor about a year ago. As you can imagine we’ve been very fast and loose with getting changes out there. I am the only person within the company currently working on customizations and early on the company had many consultants come through who have customized it. So, I’m left feeling like our system is kind of a mess and I’ve had a hard time coming up with a way to document changes in a system like this with no repositories. Within Epicor the best way I’ve found to look at changes is by going into directives maintenance and searching by directive.
Do any of you have a better way? Does anyone have what they think is a pretty good setup where they’re documenting Epicor changes outside of the system? We have tried to keep up with it some in SharePoint but there just hasn’t been time for me to get something properly setup, and I honestly don’t even know where to start.
Maybe this is just a rant, but if anyone has any tips they would be greatly appreciated.
Each post is a new / update and we track components and implementation notes etc. @jgiese.wci does similarly with Confluence
We have tried to keep up with it some in SharePoint but there just hasn’t been time for me to get something properly setup, and I honestly don’t even know where to start.
This right here is a huge mistake IMO, take the time to set-up something and keep it up to date just add documentation time to your development time make it so, force otherwise you will find yourself in a never ending hole of debt that you will not be able to get out of.
I basically force our dev team to keep the documentation up to date as you do it. Added a new field? go update docs… Created a customization? Go update docs.
We have a dashboard to show BPMs, customizations, Functions, etc. and it helps a little. We’ve always wanted to implement a Dev-Ops esque source control system but keep pushing it off.
Depending how the system is setup, it would be cool to run a query of all customizations and compare it to the “known” documented items. Maybe even add the new ones so that someone can come behind and add the missing data. Also, keep track of date last seen to see if any have been removed.
Absolutely. It’s great to view where BPMs are setup. But I can’t filter it down to enabled BPMs for example. Agree though, what is a problem though is Application Studio in Kinetic. I can see there are layers for example but there is no way to tell what are base events, views, etc vs what has been added to the layer.
Will admit it’s a bad habit I’m in. Constantly trying to move on to the next thing. I will probably have to look for a way to better track it in SharePoint as I don’t think we’ll want to purchase another subscription right now.
I think I’m going to have to make a webpage with links between documents and such. Your team’s system looks pretty good though.
Its literally the software running this forum it was easy to use and well known to all of us. But anything is better than just leaving it.
We just inherited a nightmare of a system from a differetn company we aquired and when I asked for documentation I was told “We never had time”
This is the file structure of the server I just logged in to, zero documentation and by the looks of it their Repository System consisted of adding a number at the end of a zip file every few days?
Our documentation is usually grouping 10-15 Epicor objects (BPM, Function, SSRS, etc.) into something bigger like “Web Integration Documentation”, etc., we almost never have individual object documentation apart from a comment header I put into most non-widget BPMs. That is the level I’d like to get to… a system with an entry for every custom Epicor object with deployment date/times and version history. It’s also a backup repository for our code. And then we could abstract most of the object names out of our “good/detailed” documentation so we don’t touch it every time to update V1 to V2…
We did just spend a lot of time and effort implementing SmartSheets for project and change management. It is working very well for us in terms of task management / approvals, keeping development flowing and everyone on the same page. But it’s not a Source Control system and while the last thing we need is yet another system, I’m hesitant to shoe-horn something into SmartSheets that it wasn’t built for…
If I understand correctly, I found this works until there’s an object shared between two different “solutions” like a BAQ. If that won’t happen to you, then you’re good. Otherwise, I found I was clobbering one artifact instead of merging the changes between the two solutions. Last one in, won.
Separately, I think this was a problem in Solution Workbench if we didn’t rebuild every solution that included a shared object.
I gave up. After all, I’m not modifying Epicor DLLs.
Instead, we focus on change management and project control. No matter how small a change is needed, we fork our entire environment for dev. We make a rollback CAB from prod before “merging”. We do UAT in dev, and for complex changes we first spin up a new fork and test the deployment there before UAT. The goal is to have a scalable fork/merge process that can be delegated to a theoretically infinite number of outside developers, without requiring enormous SOWs from consultants justifying ridiculous hourly rates.
I just want to stop people changing them unless they’re fully tested for functional objectives and existing processes, and unless those changes are part of controlled projects, but we’re only developing inside Epicor’s tools now. Aside from electronic interfaces, but they’re pretty rare.
I think that’s the intent of their “citizen developer” outlook, for better or worse. Knock on wood, I think it’s working for us.
it was easy to use and well known to all of us. But anything is better than just leaving it.
