Change Logs - Critical Objects - Where should logs be enabled at minimum?

After not being able to track down who setup a few thing incorrectly so we could give them some additional training, I realized logs haven’t been enabled in many areas. So, my question is, where should logs be enabled at a minimum? What areas do you enable logs in and for what reason? Any advice is appreciated. I’m sure some are pretty self explanatory, but I’m also sure there’s plenty of areas one might not even think of.

Hi Justin,

We use change logging significantly and it has been incredibly useful. While it is very useful to see who did what to records I have also found it very useful for tracking bugs both in native Epicor and in our customizations and BPMs. For instance, we found a bug in part entry that was when user changed sales unit price. Seeing change log always the same for when the bug occurred helped lead us to understand where the bug was occurring.

When we were going live we turned on changelog for all fields that we provided details in procedures for how to complete. We have many fields that are designated as “skip” in our procedures. We didn’t put change log on those. However, as we have changed over the years, sometimes we have users doing things to those “skip” fields, and when we discovered those, we turned the logging on.

While I do not have a comparison regarding speed of system with and without change log on… I do not think we are seeing much lag due to our extensive use of it. I would expect to see the lag during record save and generally opening programs, running reports take much longer than our record saves.

We did have some logs on fields that were changing all of the time and were not useful, we turned off logging on those when we realized we were logging a ton on not useful data. I cannot remember what the log was on, something to do with job numbers I think, but every MRP job was getting logged, even unfirm. That was not useful to see. :joy:

Here are our tables with logging turned on:
Table Name
ACTRevision
BookDtl
CustCnt
CustIC
Customer
CustomerPriceLst
CustXPrt
DMRActn
DMRCorAct
dmrhead
EmpBasic
InvcDtl
InvcHead
InvcMisc
JobAsmbl
JobHead
JobMtl
JobOpDtl
JobOper
JobProd
Menu
MscShpDt
mscshphd
orderdtl
OrderHed
ordermsc
OrderRel
Part
partbininfo
PartClass
PartCost
PartLot
PartMtl
PartOpr
PartPlant
PartRev
PartSubs
Plant
PlantWhse
PODetail
POHeader
POMisc
PORel
PriceLst
PriceLstParts
ProdGrup
QSalesRP
QuoteAsm
QuoteDtl
QuoteHed
QuoteMsc
QuoteMtl
QuoteOpr
QuoteQty
RcvDtl
RcvHead
Reason
Region
ReqDetail
ReqHead
Resource
ResourceGroup
RMADisp
RMADtl
rmahead
RMARcpt
SalesRep
SalesTer
SalesTrp
Security
SerialNo
ShipDtl
shiphead
ShipTo
TFOrdHed
tfshiphead
ud02
UD03
UD04
UD05
UD06
ud07
UD08
UD09
UD10
UD11
UD13
UD15
UD21
UD36
UserFile
VendBank
VendCnt
Vendor
VendorPP
VendPart
XFileAttch

Nancy

1 Like

Hi Nancy,

That’s a pretty extensive list, I appreciate this. The issue we were running into were missing GL controls on Equipment. We had a new maintenance guy start and we decided to have him try out the work queue and we scheduled maintenance jobs for him. The previous maintenance man refused to use a computer, so we never had this setup before. Well, the missing GL control on the equipment caused our Capture COS\WIP process to fail, which took me a good while to hunt down.

Thanks again!

Hi Justin,

Yep, detective work always easier with the change log. Perhaps resource / resource group logging would help with that… or a bpm to ensure it gets entered.

Nancy