I’m using version 10.200.27 (Test) ,10.200.29 (Pilot) and 10.200.27 (Live). When I create a solution that involves BPM data forms in Test and install it into Pilot or Live the EpiGuid value of the form(s) change to a new Guid value. Since I’m doing a csm.getReferenceById in the code initialization it coughs up a hairball when trying to find the Guid value from the solution. I’ve talked with Epicor about this in detail (a customization team guy), and he says it shouldn’t be happening. When you look at the xml from the customization export of the form that’s erroring out, it has the previous Guid value in all the properties of the form. But when you open the form in Customization mode and check the EpiGuid value in properties it shows a different value. We have 31 BPM data forms that we call from the Quote Entry Line screen and they are all throwing an error on loading. The form will load, but instead of being the proper size, it’s almost minimized. You can stretch it out and use it, but it is still not good to have these errors in Live environment. I’m baffled, Epicor seems to be baffled, so I hoped someone on here has seen something like this before and has a fix… Thanks!
Are you copying the DataForm too?
Yes, I put the BPM data forms in the solution.
I just checked the Ice.IPForm table in Pilot (where the error is thrown) and I see the SysRowID value is ‘757EC8DC-16F3-4175-BF69-C47F8ADBB4B7’. In the Test environment in which the forms work, the value is ‘1ea33730-f5d2-4850-8cde-6019958c7022’ which is what I used in the customization. So I guess when the BPM form runs the InitializeCode function in Pilot, it can’t find that Guid in the Ice.IPForm table so it errors out. Why would the SysRowID for a BPM form change when a solution is installed?
Why are you referencing the SysRowID?
Typically, if I am creating a BPM Data Form that I will customize, I only add a single field to the screen and then add the rest in the customization (unless it’s significantly easier to do it ahead of time). Then, if you are interacting with the screen properly, you are working with the dataView and not the controls, so no need to reference any GUID values.
That’s a great question. I inherited these BPM forms, and I’m still new to Epicor so I thought you needed to reference the form size and controlbox properties. Here’s the code in the InitCustomCode section:
‘’’
EpiBaseForm Popup = (EpiBaseForm)(csm.GetNativeControlReference(“1ea33730-f5d2-4850-8cde-6019958c7022”));
Popup.Size = new System.Drawing.Size(1150, 650);
Popup.ControlBox = false;
‘’’
I see what you mean now. I commented out the above code and the form works fine, except it has a control box which I don’t like. It’s better than an error though! Thanks a lot!! I’ll call your post the solution.
You can reference the Form by its name directly. It is the very top of the treeview on the Customization Tools Dialog.
I’ve just noticed this on 11.2.200 and 11.3.100.
First
When you deploy a BPM that references a IPForm it will even rename its SysRowID. Despite you not including IPForm it will blow it away.
[6/1/2023 2:41:08 PM] Import service(s) customization:
[6/1/2023 2:41:08 PM] Erp.BO.MiscShip.Update
[6/1/2023 2:41:08 PM] 'ADDRVALMULTICAN' Bpm Data Form exists in database and will be overwritten.
[6/1/2023 2:41:09 PM] Import finished.
Second
If you include your IPForm in a Solution it will also recreate it with a different SysRowID.
Its not even the Custom Code thats a problem anymore but the Customization Layer which has the SysRowID as a reference, will cause the Customization Code not to load and something goes haywire.
<ControlName>Customization</ControlName>
<Key>72a3e01b-bcf1-46f8-a8a1-679e38ac6bb3</Key>
It looks like InfoPromptFormSvc does get the right SysRowID with RowMod = A but Epicor still decides to ignore it and create a New GUID, especially when BPM is imported which references a BPM Form.
Since I am on-prem I have a workaround, simply modify the GUID after its been created… too much time spent drying to deploy something to Production from Dev.
But would be nice if BPMs didnt overwrite anything, besides themselves.
[6/1/2023 2:41:08 PM] 'ADDRVALMULTICAN' Bpm Data Form exists in database and will be overwritten.
I am submitting this to support @pferrington just heads-up maybe you have it in the cooker already 
CS0003711916
Dear Epicor Support,
The IPForm (BPM Form) deployments in Epicor are broken. There are two scenarios which cause a problem, the first one being the most important one, as it makes BPM Forms which have a Customization Layer useless.
Scenario 1:
- Create a BPM Form
- Create a Method Directive and use the BPM Form
- Create a Customization Layer
- Create a .cab with Solution Workbench and deploy to an Environment that already has or doesnt have the BPM Form (doesnt matter).
4.1 NOTE: In the Solution Workbench, we won’t include BPM Form, lets just assume we are updating some logic in the BPM and deploying a hot-fix to Production where BPM Form already exists.
What Will Happen:
- Epicor will detect the BPM Form in the Method Directive and overwrite it, changing its
SysRowIDwhich would cause Customization Layer Code section to totally break since the XML contains the GUID as reference.
[6/1/2023 2:41:08 PM] Import service(s) customization:
[6/1/2023 2:41:08 PM] Erp.BO.MiscShip.Update
[6/1/2023 2:41:08 PM] 'ADDRVALMULTICAN' Bpm Data Form exists in database and will be overwritten.
[6/1/2023 2:41:09 PM] Import finished.
<ControlName>Customization</ControlName>
<Key>72a3e01b-bcf1-46f8-a8a1-679e38ac6bb3</Key>
Expected Behavior:
- If we didnt include IPForm in the .cab stop overwriting it, why is the BPM trying to touch things it was not asked to touch.
–
Scenario 2:
- Create a BPM Form
- Create a Customization Layer
- Create a .cab with Solution Workbench and add IPForm, and deploy to a
new Environment
What Will Happen:
- The BPM Form will be re-created with a different SysRowID causing the Customization to break, once again.
1.1. NOTE: If you just deploy the form to an ENV that already has it, it will update it.
Expected Behavior:
- It should create itself with the same SysRowID which is provided in the .cab, or it should update Customization GUIDs.
–
In a Nutshell if I had to summarize it. Honor the SysRowID and dont let BPMs overwrite IPForms which werent included in the .cab – problem solved.
Epicor has gone back and forth a few times with what to do with dependent objects when exporting. Some like the Reports has it include all sorts of items in a total pacakge. Others do not. We need to be more consistent here. I was not aware of this bug but I will be looking for it.
I do have a Case out there if you need to reference it:
CS0003711916 - Solution Workbench - BPM Form (IPForm) Installations Corrupt
Recap:
- When Installing a BPM it will overwrite IPForm and give it a new SysRowID (this one has not been observed in 10.2.700, but in Kinetic)
- When Installing a IPForm to a Environment where the IPForm does not exist, it will give it a new SysRowID (also breaking Customization, not so much the Controls, but the
class Scriptwill becomestatic class Scriptwith code missing.)
It really comes down to just respecting the SysRowID from the .cab in the .xml
My On-Prem Workaround is a UBAQ or SQL to set the IPForm SysRowID back.
UPDATE Ice.IPForm SET SysRowID = '64F27CFE-B9DC-44CA-B089-B39DE80DFD9E' WHERE FormId = 'ADDRVALMULTICAN'
Looks like Epicor accepted this as a bug. I wanted to throw one more observation, even when I change the GUID back, the Customization will load once, but not the 2nd time. Force Validate fixed it, despite it already being in PASS State… Perhaps the SysRevID also comes into play or something else I missed. Just jotting it down, when you get to testing (but it loads fine w/ Dev Mode on), must be a cache issue, despite clearing cache. Again, once Force Validating it again, seems to be okay.
CC: @jgiese.wci
I also noticed when Exporting a BAQ with a BPM Form and then Importing it back, it will change the GUID and do an overwrite. But not Update the Customization it references…
On a side note Copy Query no longer works with a BPM Form. Probably because the copy query once again gets a new GUID and sees that it doesnt exist.
@Rich and @pferrington
We noticed that some BPM Widgets IPForm sometime target specific-company, simply unselecting and re-selecting the IPForm Customization in the BPM Editor removed company. We’ve had users complain that the Customization loads sometimes, and sometimes doesnt (assuming this key drives where its cached).
But more importantly once we reselected it, Epicor modified the the DirectiveDefinition from System.Private.CoreLib back to mscorlib (isnt that backwards going from .NET Core to .NET 4.x again)
Whats the story behind CoreLib vs mscorlib and why are we heading back to mscorlib?
SELECT * FROM Ice.BpDirective WHERE CAST(Body AS NVARCHAR(MAX)) LIKE '%CoreLib%';
SELECT * FROM Ice.BpDirective WHERE CAST(Body AS NVARCHAR(MAX)) LIKE '%mscorlib%';
Looks like if you include the IPForm now with a UBAQ, lets say you made some changes to some buttons it breaks during import on 2024.1
Second if you just package the IPForm it wont import even if you made tweaks
[7/25/2024 3:07:01 PM] Import of IPForm record '9b4e7a97-db99-4397-9b81-2a93b7e89cc3' was cancelled. Record already exists.
Update on this, this was related to using MESRevertToOriginalUser in our .sysconfig. When an Employee doesnt have EmpBasic.DcdUserID defined then Epicors logonNewUser() or so wasnt being called, and the first BPM Form didnt send over the company (race condition in MES). Unrelated to BPM Forms or GUIDs.