Since many places, especially in regards to purchasing, refer to an assembly sequence number, it would be incredibly useful to have a find by assembly sequence number in the job trees. Currently if I only have an assembly sequence number, I open up job traveler print to use the filter screen to find the part number. Then I search for that, and if it’s used in more than one place, I have to keep searching to find the right one.
In the same breath, a “find next” option when searching by part number on that search box would be great!
You can add this one yourself with a little bit of customization.
Here’s a quick one boiler plate. You’ll have to write the actual lookup yourself but it gets you most of the way there
// **************************************************
// Custom code for JobEntryForm
// Created: 7/26/2018 12:18:09 PM
// **************************************************
extern alias Erp_Contracts_BO_Project;
extern alias Erp_Contracts_BO_Part;
using System;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Windows.Forms;
using Erp.Adapters;
using Erp.UI;
using Ice.Lib;
using Ice.Adapters;
using Ice.Lib.Customization;
using Ice.Lib.ExtendedProps;
using Ice.Lib.Framework;
using Ice.Lib.Searches;
using Ice.UI.FormFunctions;
public class Script
{
// ** Wizard Insert Location - Do Not Remove 'Begin/End Wizard Added Module Level Variables' Comments! **
// Begin Wizard Added Module Level Variables **
// End Wizard Added Module Level Variables **
// Add Custom Module Level Variables Here **
MenuItem findAssy =null;
public void InitializeCustomCode()
{
// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Variable Initialization' lines **
// Begin Wizard Added Variable Initialization
// End Wizard Added Variable Initialization
// Begin Wizard Added Custom Method Calls
// End Wizard Added Custom Method Calls
findAssy = new MenuItem("Go To Assy Num", new EventHandler(cmFindAssy));
oTrans.JobTree.BeforeShowContextMenu += new Ice.Lib.Framework.JobLib.MethodTree.BeforeShowContextMenuHandler(jobTree_BeforeShowContextMenu1);
}
public void DestroyCustomCode()
{
// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Object Disposal' lines **
// Begin Wizard Added Object Disposal
// End Wizard Added Object Disposal
// Begin Custom Code Disposal
// End Custom Code Disposal
oTrans.JobTree.BeforeShowContextMenu -= new Ice.Lib.Framework.JobLib.MethodTree.BeforeShowContextMenuHandler(jobTree_BeforeShowContextMenu1);
}
private void cmFindAssy(object sender, System.EventArgs e)
{
MessageBox.Show("Do Search ,lookup work here");
}
private void jobTree_BeforeShowContextMenu1(object sender, Ice.Lib.Framework.JobLib.MethodTree.NodeArgs e)
{
oTrans.JobTree.TreeContextMenu.MenuItems.Add(findAssy);
}
}
I (unfortunately) don’t have the technical skill to finish this solution, or I probably would.
I do think that this is a universal enough tool though that it should come out of the box from Epicor. Hence, why I put it in the feature requests and suggestions.
Could prob even create your own Dockable Tab and move the TreeView or TreePanel into your custom Tab (might have to do it via code) and then on top add filtering features via normal Customization =)
Example: This Panel has 2 textboxes and a Nav Control above the Tree.
couple of things that need to be change. (and I only am working with assembly sequence because material sequence are duplicated too many times to be useful)
FIrst, AsmSeq isn’t the right column name, it needs to be AssemblySeq
After wasting a ton of time writing up a bunch of screen shots showing my testing, and realizing “no one cares about your testing”, I finally figured out that this search method will only search one level down from the assembly that you clicked on when you do the search.
This will need to iterate through the whole tree no matter where you are clicked on to make this useful. Since if I need to know the parent assembly, I am already only one click away anyways.
And I also commented out the “oTrans.JobTree.ExpandAll();” line, because it was really confusing…
It’s pretty close. Can it be made to look through the whole tree?
Can it be made to search the whole tree. Yes, thought it would require some rework. Currently, it just looks at the jobAsm dataview - which I assume is parented (subscribed) to the parent asm - this is the reason it’s always looking at the tree level down.
I suppose a more flexible approach might be to crawl the tree itself (as opposed to the jobAsm dv) looking for Asm values matching your desired value BUT - we would also have the caveat that with a complex BOM, you could have multiple, nested ASM 0’s (or any asm) - I suppose it may be more useful to have the input box stay visible (until explicitly closed), this way - you could just keep hitting search until you get to the desired level. This should only start searching from the currently selected tree level. Definitely more involved.
Another fancier option might provide a list of all matches, that you can select from.
I wouldn’t need the search if we didn’t have complex boms, now would I?
I’m assuming that this is what the built in search does. Can we just hijack the programming used to make that and replace part number with AssemblySeq?
AsmSeq numbers are unique on the job. MtlSeq numbers are not.
This would work (be great!) for a part number search. I would not be necessary for assembly sequence number search though as there is only one per job of a certain AssemblySeq number
Not sure it this will help in your case
I ended up adding a listview for assemblies that seem to help users working with complex structures. Pretty simple/easy to build - a BAQ, Dashboard & sheet wizard in Job Entry/tracker.
Note this dashboard really will show all parents and subassemblies, however the job displayed in this screenshot only had parent zero.
I had originally intended to modify the TreeView, but ran it similar issues with complex structures, many levels/subassemblies.
Was taking too much time & finally put it aside.but… thanks for shared the examples & ideas. I might try attacking this again… some day.