I guess it depends on how you want to view the information. A few different ways to “skin the cat” I think. And I’m typing out loud as I think through this, so hopefully its not incoherent (and others can correct me if I’m wrong in my thinking).
Are you running your BAQ against a single PartNum? In that case, you won’t have a PartNum to run it against until a line is created. So you would want to perhaps tie an event after ColumnChanging_PODetail_PartNum.
At that point, PODetail.PartNum is populated with a value, so you can use that to run your BAQ against.
This would then populated your BAQ Dataview and you would see the field value you’re looking for (in theory) on the form. But the dataview would only contain one row corresponding to your partnum.
So, if you then click over to a different line item (which has a different partnum), you would also need an event there to refresh your BAQ again following any rowChanged event.
Alternatively, yes, you could run your BAQ after an onload event, run it wide open (not using a specific partnum against the BAQ) and it would populate many rows in your dataview. In that case all rows would be there to easily reference based on various PODetail.PartNum (s) across multiple lines. So, that’s perhaps a better approach as long as running the full BAQ wide open doesn’t have a performance impact.
ANOTHER alternative… you could possibly forgo the BAQ & BAQ dataview and add the native Part dataview into PO Entry. The Part Dataview should already include your new UD column. But, here again, you still need to create an event to populate that dataview. You would just use a rest-erp instead of an erp-baq event widget. I did something similar in the below post. I wanted to get Requisition information (the name of the person requisitioning) visible on the PORelease Detail. So, the steps would be similar.