Instead of doing some crazy BAQ to calculate which jobs are current, available and expected, is there a way to grab those directly from the work queue using a customization, or code of some sort?
No doubt you have have worked this one out by now. You can use the WorkQueue.GetRows method. The RegionCode gives you the different status:
Region 1 = Current work ( if started or complete or 1st operation on assembly without children),
2 = Available work (if preceding operation actual qty > 0),
3 = Expected work. (none of the above ),
4 = Current work with current shop employee working on it (I think this goes in the Active Work Tab on the Work Queue form)
1 Like
Hi @Hally,
I’ve created a BAQ that I have been asked to get filtered down to the current work queue. Meaning, I only want to show the operations that are in the current work queue. Is the best way to go about this by making the BAQ updatable and then creating a BPM on the GetList method in pre-processing? I feel like there are multiple ways to go about this but am unsure of the best way to do this.
Would also like to add that I tried hitting the API to retrieve all jobs where RegionCode eq 1 and received an error. Is this still the way things are done?
Any insight is appreciated!
Try GetOpsInResourceGroup
This was a while ago…I’ll have to go back and take a look. Sorry for not replying earlier, as far as the best way…The aim these days would always be to ensure you don’t need a classic customisation layer on top. Using an Updatable BAQ has merit… Others with more experience and expertise may have other suggestions.
I really wish there was a good way to do a BAQ of the WorkQueue.
Sometimes departments want digital signage that display a Resource Group or Resource or Department’s Work Queue as just a visual aid. The real need is to be able to sort by the ‘Region Code’ first and then the Operation Start Date so what is Current and Available to be done is on top no matter if it’s scheduled start date since Current Work is what can actually be done.
I just wish I knew what WorkQueue.GetOpsInResourceGroup was actually doing to determine the RegionCode since it seems pretty fast. Same goes for the Priority Dispatch Report as it does the same thing.
Check out the system BAQ zWorkQueue, it may give you some answers
Thanks @tkoch I didn’t check for System BAQ’s… this looks like this might be used for initial generation of the data set for the WorkQueue, but the Query doesn’t set the RegionCode… I think I’m going to start with this though and dig in a bit more to understand what it’s doing and see if I can calculate the RegionCode…
You can decompile the Erp.Services.BO.WorkQueue to see how it is calculating the RegionCode. Your best bet is to create an updatable BAQ and override GetList to call WorkQueue.GetOpsInResourceGroup and then you can manipulate and return how you want to present the WorkQueue data
Ok so I’m back at this again, but a different angle, gonna just call WorkQueueSvc/GetOpsInResourceGroup and present the data in a grid… super simple, everyone seems to want displays showing what a given resource is currently working on and what’s next in their queue… nothing interactive, just big clear visuals.
So I’ve been poking around the API with GetOpsInResourceGroup andI get data back fine enough, but I’d like to have the API to only return records of certain RegionCodes. I saw there is a parameter called ‘FilterParameters’ but playing with it I can’t work out how it should be used.
Also I tripped across another call ‘GetOpsInResourceGroupWithBaq’ this looks interesting but I can’t work out effectively how to use it, nor what it would do exactly. Might not be helpful at all but it looked interesting and I didn’t know if anyone had any insight.
Just an update. While in a lab at Insights I suddenly realized I can call an Epicor Function via REST, I this this really solves everything… I think I can build out a Function that handles all the various method calls, merges, filters and sorts the data and then just return that to the browser for display. Why did I think fumbling with multiple REST calls and all this in JS was the best way… This way seems to be much lighter on the browser and reduces server traffic and puts all the work on the server… where it should be.
1 Like
Another update, creating and calling an Epicor function is the right way to go and it’s working well. As like many projects the scope creeped and I needed to make several checks and other things so I ended up making several method calls in the function to get the data needed… way more than I thought.
Only real open item is the purpose and usage of the ‘filterParameters’ in the GetOpsInResourceGroup… just can’t work that out… don’t NEED it but I could simplify the function design if I could add additional filters to the method call.
1 Like