We deployed our first Product Configurator in March and it is being heavily used by our salespeople. Of course, now everyone is excited to add more options and/or tweaking the options offered.
Due to recommendations given at last years conference, we developed a lot of our functionality using the PClookup tables. This works great but very quickly we realised that this was a weak link in our change control process. The BPM option to add a change log in the data directive is not activated.
I asked the question at this years conference in Timâs session on Advanced configurator and there was no solution. One person suggested I use a BPM to copy to an audit log in a UD table. In looking at adding this, I found this post from 2015:
I adapted this and was able to do the following updates to our database:
Update ice.ZDataTable set ChgLogID=âPcLookupColSetHedâ, TableLabel=âPcLookupColSetHedâ where DataTableID=âPcLookupColSetHedâ
Update ice.ZDataTable set ChgLogID=âPcLookupColSetDtlâ, TableLabel=âPcLookupColSetDtlâ where DataTableID=âPcLookupColSetDtlâ
Update ice.ZDataTable set ChgLogID=âPcLookupTblHedâ, TableLabel=âPcLookupTblHedâ where DataTableID=âPcLookupTblHedâ
Update ice.ZDataTable set ChgLogID=âPcLookupTblValuesâ, TableLabel=âPcLookupTblValuesâ where DataTableID=âPcLookupTblValuesâ
From there I now had the Change Log icon on the data directive and could continue to configure this.
The one quirk I did find was the icon on the maintenance screen did not indicate there was a change log entry for the table I was editing but when I ran the Change Log report for the PCLookup tables it did report the changes made. My plan is to just run this weekly to indicate to the key parties what was changed.
Not normally. The fact that the original post was from an Epicor Support person gave me some confidence. I tested this first and confirmed the functionality worked.
I guess my post should have the warning that you make this change at your own risk and contents may settle during shipping and your experience may differ from mine!
While the warnings are implied, I was more curious about how it might affect things down the road, like updating a db for a version change. Best case, it has no effect, 2nd best case, it just needs to be preformed again, and no prior change logs were affected. Worse case, the new version doesnât work.
Also⌠The Data Dictionary description for ZdataTable.ChgLogID is:
Identifier value the system will use when creating Change Log records for this specific table (ChgLog.Indentifier) ChgLogID must be the same for a set of related tables. For example: Customer, ShipTo, CustBillTo, CustCnt, are all related and will have a ChgLogID = âCustomerâ. TIP: Using the tablename of the highest level parent table as the ChgLogID may avoid accidental duplication.
So shouldnât all of the Update commands in that SQL script have set them all to have the same ChgLogID, instead of independent ones?
Hereâs a query of the ZDataTable for TableID <> ChgLogID
When I brought up the lack of some tables having the change log in a support ticket in 2017 there was no solution by the support analyst. I asked at the 2018 conference and there is a new change log process going to be implemented âreal soon nowâ but I suspect that they have lots of other items ahead of that. (Change logs are not as sexy as IOT!
I noticed that there were a few tables in zDataTable that are inconsistent so you raise a good point that I might bump into an upgrade issue later on. Seems like the âListâ tables are some kind of temp table.
