Erp_Proxy_BO_PartImpl_UpdateExt_Request (can update company but not part plant)
I can pass in a companyid just fine. I set updatepartplant to true within the data set, but it’s not updating. How can I update the part plant? I’ve also looked into using the PartImpl_Update Method too.
I think you need to change the RowMod to U. I don’t know if that one shows up in the regular selection however, so I think that you would need custom code.
@Mark_Wonsil do you know how to get around that limitation in a cloud setting?
Hey Brad,
Take a step back for a moment and tell us what you’re trying to do from a business point of view and then we can get into the technical side.
Mark W.
Did you do a trace? Do you know about trace?
@Banderson I have tried to alter the RowMod to U (could try a different way of mapping I suppose). @Mark_Wonsil This is in Service Connect. I have a conversion that I’m doing before a call to the UpdateExt_Request. I am trying to create a part in a lower company based off of the parent company. I can pass the CompanyID in the request to the method and it’s able to create it just fine there, however when I try to set the site, it isn’t taking.
Workflow: Does part exist? No.
Run PartImpl.GetByID (from parent company).
Then run PartImpl.GetNewPart followed by PartImpl.UpdateExt.
@josecgomez Yes, I have been doing tracing within Service Connect. I can read the inbound msg and examine what’s happening at each part of the workflow. I am also decompiling the .NET assemblies to see what’s happening behind the scenes when a Request is made and what method is ran (parameters, etc).
P.S. I hope this makes sense
I tried to help and we spent 2hrs we couldnt get it to work.
When you create a Part for the first time Epicor automatically will create the PartPlant for you with the plant you are currently logged in.
So in Service Connect on the Workflow Properties we have it set for the account to login into Company A and Plant A, but, unless we go to the Full Client and login as the “manager” account and change the Plant, it will be stuck like glue. Because someone logged in as manager and used Plant C at some point.
Whatever we do, the SC BO Calls seem to continue to target the wrong plant, assuming that the manager is still logged into Plant C and not Plant A.
By the way he is using UpdateExt (older flow someone made)… We made an Updatable Dashboard to test the theory that UpdateExt isnt doing its job and it worked fine in an Updatable BAQ, we created a Part and Epicor created the other child tables with the right logged in Plant.
Well thanks @hkeric.wci . That is a better way to explain it. Taking note. I still need to experience more debugging through an updateable dashboard; that was super cool.
Well their workflow is already BOs and I dont think they have REST configured yet, or are trained on it… The only other way I can think of is, Create the Part and let Epicor add it to the wrong plant or right plant and then delete the PartPlant record with RowMod “D” and simply create a new one, without the assistance of Part.
Because the CallSettings in SC don’t seem to work right.
@bradberkobien additional debugging you can do is…
Method Directive on Part.UpdateExt (PRE and a POST) and then make a Data Directive on PartPlant (In-Transaction) and simply do something along the lines of this in a Custom Code Widget:
Ice.Diagnostics.Log.WriteEntry("Inside UpdatExt PRE!!!!!"); // change for POST and change for PartPlant In-Transaction
foreach (var row in ttPartPlant.ToList())
{
Ice.Diagnostics.Log.WriteEntry($"User Company: {Session.CompanyID}");
Ice.Diagnostics.Log.WriteEntry($"User Plant: {Session.PlantID}"); // check this im guessing its PlantID
Ice.Diagnostics.Log.WriteEntry($"Part: {row.PartNum}");
Ice.Diagnostics.Log.WriteEntry($"Part Plant: {row.Plant}");
Ice.Diagnostics.Log.WriteEntry($"Part RowMod: {row.RowMod.ToString()}");
}
Then if you go to the Server Folder on the IIS (Epicor Server) and look at ServerLog.txt those diagnostics logs will write there, then you can see what Epicor had internally.
Currently debugging will get back to you soon
I have added the logs to method and data directives and have attached the Server Log to this post.
foreach (var row in ttPartPlant.ToList())
{
Ice.Diagnostics.Log.WriteEntry($"User Company: {Session.CompanyID}");
Ice.Diagnostics.Log.WriteEntry($"User Plant: {Session.PlantID}"); // check this im guessing its PlantID
Ice.Diagnostics.Log.WriteEntry($"Part: {row.PartNum}");
Ice.Diagnostics.Log.WriteEntry($"Part Plant: {row.Plant}");
Ice.Diagnostics.Log.WriteEntry($"Part RowMod: {row.RowMod.ToString()}");
}
Ice.Diagnostics.Log.WriteEntry("Client Company: " + callContextClient.CurrentCompany.ToString() );
Ice.Diagnostics.Log.WriteEntry("Client Plant: " + callContextClient.CurrentPlant.ToString() );
Ice.Diagnostics.Log.WriteEntry("END UpdatExt PRE!!!!!");
Note: Service Connect calls the Ice:Lib:SessionMod/SessionModSvcContract/SetCompany but never the SetPlant.
Here in this conversion of the workflow shows where I set the PartPlant:
debug.txt (17.2 KB)
@josecgomez I implemented a hack for now until I can get SC working correctly.
Within the Pre-Processing for UpdateExt Method directive, I set the session’s plant to the client’s current plant like so:
Session.PlantID = callContextClient.CurrentPlant.ToString()
Interesting @josecgomez
The Call Context switches, but Session doesn’t
<IceAppServer msg="User Company: 01800000" />
<IceAppServer msg="User Plant: 003000" />
<IceAppServer msg="Part: yoheyo" />
<IceAppServer msg="Part Plant: 003000" />
<IceAppServer msg="Part RowMod: " />
<IceAppServer msg="Client CallContext Company: 01800000" />
<IceAppServer msg="Client CallContext Plant: 001000" />
<IceAppServer msg="END UpdatExt POST!!!!!" />
He does have on the workflow you can go to Properties and Login Tab the Plant Specified. Epicor seems to change Companies but not Plants.