I am looking for a way to programatically check in and check out a part revision to a given group automatically without displaying the UI for description/notes/reason.
I am unable to set the GroupID and the CheckedOut values in the ECORev table within the EpiDataView (It blows an error and says I cannot set those values). Also I do not see a way to programatically remove/delete records from the ECOMtl and ECOOpr tables.
The full scope of what I am looking to do is:
Check Out Part Revision to a statically named Group
Unapprove Part Rev (I can do this via the EpiDataView)
Clear All (delete the associated Mtl and Opr records for this rev)
Approve Part Rev (I can also do this via the EpiDataView)
Check Part Rev Back In
I am interested in doing this directly in the code or if necessary via REST.
Hi Ethan,
Your profile shows that you are on 10.2.300, is that still accurate? In 10.2.500 Epicor introduced the concept of ‘Functions’, which is very similar to a BPM but can be triggered on demand. I think this would be a good use case for a function. Directly setting values in dataviews is probably not going to give you the results you want.
First I would turn on Tracing, then manually perform each of the steps you outlined here in the client. Make note of each method call that Epicor is making in order to do this.
Then, create a function that calls those same methods with the appropriate parameter values.
Finally, add a button to a UI customization that would call the function, passing the appropriate PartNum and RevisionNum values.
If I didn’t have Functions available, I would maybe create a small web service that performed the method calls via the REST API, and call that web service from the UI customization.
Here’s a UBAQ that has the code in it for checking out parts. That should get you started
Why though? Epicor native doesn’t remove lines from the ECO tables. Just leave them alone, and you shouldn’t be using these tables for anything other than info for currently checked out parts.
REST only adds the capability to call stuff from outside of the system. If you are already in the system (BPM/UBAQ etc) you can do anything you would be doing with REST. It won’t give you any extra abilities.
This is definitely possible, so post your code and errors and someone can help you with it.
So…I’ve waded neck deep in this area of the system because I had to bolt on something approximating a proper rev-control system onto Epicor. Last month I rewrote all of it as functions, so this is all very fresh to me.
Are you just futzing with the dataview/datatable and running update? It sounds like that’s what you’re doing and that is…not how to do this. I don’t think you ever need to set the EcoGroup in a table. When you need to add records, the BO call has the GroupID as an input parameter.
I am still on 10.2.300 but we are migrating to Kinetic very soon. I have tried tracing but this still leaves me with the undesired result of opening up UI interfaces. I may bite the bullet and just develop it in Kinetic and investigate doing it in a function. Your suggestions are appreciated!
You use the UI interface to get the trace to find the methods you need to call to make the code work. That doesn’t mean you have to open the UI within your code…
I am still new to developing in Epicor, you may be entirely right. I just noticed it was calling the checkout screen and passing in parameters. Maybe I need to be looking at the trace data from the checkout screen itself. Thanks for the suggestion.
I don’t think anything you’re doing requires UI interfaces. InvokeGetDetails() might create a pop-up, but the underlying GetDetailsFromMethods() doesn’t.
I can get you a decent list of method calls from start to finish. I also have some old classic form code from the prior implementation of a button that copies all of the alt methods from a base rev to a new rev and then pulls MOM details on all of the methods to the new part/rev.
I will take a look at the UBAQ info you linked to, thanks for the suggestion. And on a note about the ECOMtl and ECOOpr records being removed, I am not 100% certain what they do, I was just told they need to remove them? New to Epicor dev and the parts screen, learning as much as I can though!
Okay, first off, you’ll want to call the EngWorkBench adapter. You’ll be calling pretty much everything from there.
I think this is roughly what you need to do to just check out the part, nuke the details, and check back in. You’ll have to look at the method parameters in object explorer. There’s a lot of them and adding them would clutter the code snippet up. Most of them are obvious anyway. If not, set them to false/blank.
using (var adapter = new EngWorkBenchAdapter(oTrans))
{
adapter.BOConnect();
adapter.CheckOut(...)
//this should also unapprove the part, so you can skip that step.
//I believe ipReturn needs to be true to return the dataset for the following calls.
adapter.ClearAll(...);
//I don't *think* you have to loop this if you have alt methods.
var ecoRevTable = adapter.EngWorkBenchData.ECORev;
foreach (DataRow row in ecoRevTable.Rows)
{
if ((string)row[ecoRevTable.PartNumColumn] == "YourPart" &&
(string)row[ecoRevTable.RevisionNumColumn] == "YourRev")
{
row.BeginEdit();
row[ecoRevTable.ApprovedColumn] = true;
row[ecoRevTable.RowModColumn] = "U";
row.EndEdit();
//This will mark the main and alt methods as approved.
}
}
adapter.Update();
//You might need to move this into the loop.
//Sometimes the system gets angry when you update multiple rows in one go.
EngWorkBenchAdapter.CheckIn(...)
}
SUPER appreciated, between your snippet, looking at the correct Adapter (EngWorkbenchAdapter) and following the trace on the correct screen, I believe I was able to identify the final pieces I needed to make this happen. I owe you a
