I’d like to create a BAQ Search for our Incoming Intercompany PO Suggestions. However, it looks like the base data for this resides in IMOrderHed, IMOrderDtl, and IMOrderRel, none of which appear to be available for a BAQ.
You are correct Todd. @hkeric.wci may know a way to get them to show…
But for mere mortals, I did a BPM using one of the Get or Search methods and you can filter from there. You can’t change the grids in a search without the SDK but you can “steal” a field or two.
I think what I did was a Method Directive on the SOPOLink.GetList method, which is the method called for the search. The ttIM* tables are available in the code block and you can use the Db context to read across companies - so make sure you have your company selection set properly. This will give you an idea - not tested.
foreach (var curOrderHed in ttIMOrderHedList)
{
var PORelRow = (from PORel in Db.PORel where PORel.Company == curOrderHed.ExtCompany && PORel.PONum == curOrderHed.ICPONum select PORel).FirstOrDefault();
if (PORelRow != null)
{
... look up your job header here once you get our PORel row...
}
}
Thanks Mark. Unfortunately my coding skills are fairly weak so I’m not able to finish this off with your approach.
However, I was able to get what I needed with more of a “brute force” method… Since the IM tables are available through SQL Server, I set it up as an External Data Source and then wrote an External BAQ, and a Dashboard that uses it, which I added to our standard Incoming Intercompany PO Suggestion form…works great!
Not really. I would say that the External BAQ is cleaner than the DB context. SaaS users can’t use External BAQs so we had to resort to the DB context, which bypasses object security as well.