The issue is on 2025.2 and the Kinetic Screen for Conversion Workbench only lets you do 80 conversions. Well there are now 91 conversions so the last 11 can’t be run from the Kinetic Workbench. Like at all just not possible wihtout hacking the Kinetic layer.
I haven’t yet had time to look at it, but presumably they have a way to detect if the directive has already been processed by the rule… I expect there is a way to fool the rule into ignoring the directive by modifying some field in Ice.BpDirective…
Would help to be able to read the source code for the conversion rule…
Thank you, @DeanMiller. We will be reviewing this.
Anyone else have specific examples?
We’re SaaS but don’t have a spare environment to run it. You’re free to take a copy and test with it.
All my examples have been corrected. I had the same issues for at least 5 customers.
Mine were corrected also , I was able to compare to what is in Production right now. Have you corrected Production as well as Pilot ?
I had a BAQ where I created a calculated field combining memo text fields from a header and a detail record. I added blank lines and three dashes for readability, and the formula was something like this:
‘(Header)\n’ + MemoH.MemoText + ‘\n\n— (Detail)\n’ + MemoD.MemoText
I forget the error I was getting, but I got an error on saving this BAQ. I ended up figuring out it had to do with the “—” I had embedded in the formula. I changed this to a single dash (probably could have put spaces in the dashes, so “- - -”), but that got rid of the error.
So, looks like they just don’t like a “–” even in calculated fields.
@SimsTrak, I’m running this through our tool and I’m not seeing the code being fixed. This is the code I tried with:
var x = "(Header)\n" + MemoH.MemoText + "\n\n— (Detail)\n" + MemoH.MemoText;
If you could get the actual code, I might be able to reproduce.
I think he posted in the wrong thread. He’s talking about Calculated fields in a BAQ.
Not related.
I value all of your input and comments here. The information shared is very useful for Epicor to learn the state of the product. This topic is highly visible with Epicor leadership, and is not being taken lightly. I can commit to you all that we’re working towards a resolution. I’m also working with our internal teams to improve our processes. I appreciate your patience.
I just got a closure on my Case and this has officially been addressed as follows according to the Response on my Ticket
CASE: CS0005187864
Solution:
This is an issue that has been addressed by ERP-165176 in Kinetic 2025.2.8 and later.
ERP-165176 no longer touches custom C# code. It is left for manual correction after an update.
Thanks to Epicor for addressing this, there is no backwards fix once the code is touched is touched but going forward this shouldn’t be an issue any more. ![]()