Any way to speed this up?

Epicor ERP 10
1

Does anyone have any idea how I can speed this up? All I am tying to do is assign the related op to 10. I don’t know what the BO is looking at, but once you get into a large assembly, it takes forever. See the gif. (yes it does change it just is reeealllly slow)

I can’t really do anything about the size of the assembly. Any ideas?

slow%20Work%20Bench
slow Work Bench.gif1915×1018 187 KB

2

Tried using DMT??? From a process point of view it wont be any faster and in fact probably slower but it will free your time up while its updating.

3 Likes
3

Paul has the best solution for going forward. In the future, make sure your operations exist prior to importing part materials. The default related operation is 10, and you won’t need to go back afterwards and mass-update.

4

I can’t do that, the BOM in imported using CADLink, which creates the part numbers and the BOM’s. We use engineering workbench to add the operations because the operations portion of cadlink is too hard to use.

5

copy those lines, delete from this MOM, change the op in the copied data, paste Insert ??

6

How about a BPM that fires during import, which sets the related operation to 10?

7

my suggestion then is to get a modification to cadlink, ie a button that would default all material in a subassembly from a displayed value (this can change). We have been meaning to get this done for exactly the same reason you have. We also use part templates for operations in cadlink

8

There are no ops at import. Therefore no OP 10.

One thing I have found, when doing some testing, it to collapse the tree all of the way first before changing the ops. General use is I expand the tree, and collapse assemblies that have operations to make sure everything is done. I’m guess that this is loading the whole tree into the dataview. If I don’t expand the tree, it’s still slow, but not excruciatingly so.

9

Could you add just one generic operation in CADLink?

1 Like
10

Customization… with the ability to pull in the Related Ops from a Previous Group for that Part…

2019-02-12_1609
2019-02-12_1609.png818×188 63.2 KB

Defaults to 10 if 0 and no Previous Op found…

trara
trara.gif1015×747 798 KB

11

One thing you should know… If you do anything via code, like a foreach… you MUST Be on the Materials List Tab or Epicor will reject your Row via RejectChanges(); Looks like hardcoded garbage in the UI .dll…

Had someone who had the SDK look into it for me as well to find a comment that stated something along the lines “In order to avoid XYZ Bug SCR… We will reject any Row changes if not on the Material Sheet”.

I used

public void InvokeFocusMaterialListTab()
    {
        // Switch to the ECOMtl Panels and Tabs
        var mtlSheetPanel = (Erp.UI.App.EngWorkBenchEntry.MaterialSheetPanel)csm.GetNativeControlReference("44bdf5a4-7bc0-4221-8d46-2357e127b247");
        mtlSheetPanel.ActivateSheet("materialDetailPanel1");
 
        var txtPart = (Ice.Lib.Framework.EpiTextBox)csm.GetNativeControlReference("c75de9d3-8ea7-4b05-b08b-8eed8d7c4796");
        txtPart.Focus();
        mtlSheetPanel.ActivateSheet("materialListPanel1");
 
        var mtlListPanel=(Erp.UI.App.EngWorkBenchEntry.MaterialListPanel)csm.GetNativeControlReference("420cc2c2-06c6-4fa3-bc48-b0e37ee9b06b");
        mtlListPanel.Focus();
        mtlListPanel.Show();
    }

EDIT: Found it in an Email (EngWorkBench UI dll)

case "RelatedOperation":
//For some reason, when the ECOOpr.OprSeq was modified on a new row, the RelatedOperation
//was sometimes being modified on the ECOMtl row.  This should not happen.  At this point, the 
//BL and UI have been unable to determine what is causing this to occur, so as a workaround, if
//the user was not modifying the ECOMtl view, then we reject changes on the ECOMtl row.
if (this.LastView != this.ecoMtlView)
    e.Row.RejectChanges();
break;

If you are setting RelatedOp via code in C# you would pull your hair, if you didnt know about this, so make sure you give the Material List tab Focus or changed the LastView :slight_smile: Welcome to Epicor inconsistencies 101 =)

So In @Banderson case he could create a button to Switch Tabs (Use snippet above), Foreach on DataRowView to update the RelatedOperation to 10 for each Mtl Row… oTrans.Update(); oTrans.Refresh(); and easy peezy.

It would run faster than Paste Update… because you can modify all of them and call oTrans.Update() once… I can modify 500 Materials within 2-3 seconds.

1 Like
12

Or just put the button on the material tab, right?

I’ll experiment with some stuff and see what I figure out.

1 Like
13

Yes sir! It would work then…

EpiDataView edvMaterial = this.oTrans.Factory("ECOMtl");
foreach (DataRowView row in edvMaterial.dataView) { 
  row["RelatedOperation"] = 10; 
}
oTrans.Update();
oTrans.Refresh();
14

Can’t you still set the Related Operation to 0?

15

I can, but I need it related to an operation because we back flush. And we have other customizations built on the assumption that materials and assemblies will be related to operations.

16

I got it implemented. Thanks @hkeric.wci. I couldn’t get the button onto the list tab because the grid wouldn’t allow me to move it to fit in there. So I put it on the the detail tab and did your focusing tricks and it works. I just tried some preliminary testing, so we’ll watch to see if it gives us any hiccups with more regular use.

1 Like
17

Just for future reference, the line oTrans.Refresh(); isn’t necessary for this specific case. The reason that it’s a problem (nuisance really) is that if you are working 2 or more levels deep in a BOM and it refreshes, it refreshes the tree and you lose your place in the BOM. I just commented out the line, and the update happens in the UI without needing the refresh. I’m assuming there is a DataViewNotification somewhere in there that updates the UI.

18

I needed the Refresh for the RowRule’s to play nice, your right its not necessary in your case. Now that I recall - I couldn’t get the RowRules to refresh properly.

1 Like