Has anyone worked with the Purchase Order Suggestion Entry form (called from Buyer Workbench)?
I am attempting to add some columns to the Purchase Order Suggestion Entry > Material List data grid.
I have successfully done this before with other data grids following josecgomez’s post “Efficiently Adding Column to DataGrid”.
The issue is that the Buyer is selected on the Buyer Workbench and passed to the Purchase Order Suggestion Entry form and I cannot figure out how to capture that parameter. The new columns I added do display in the data grid, but no records.
I get an error when the PO Suggestion Entry form opens.
Error is: Key not found: ‘BuyerID’
Parameter name: key
What I have tried…
string pubBinding = “cmbBuyer.value”; //PurAgent.BuyerID"; //“POTotal.BuyerID”; //“SugPoDtl.BuyerID”;
I assume, based on your error, that you just replaced the binding on the material sheet grid to be your BAQ dataview. I would not do that based on the fact this controls the main screen (i.e. highlight a row in the grid and the tree selection and details change. That is causing your initial error because BuyerID no longer exists. Are you looking for a buyer to click a single suggestions in the workbench and have it open with All but the selected one in focus? You could add a new sheet and grid, bound to your BAQView, to show all material but this might not be what you desire as it will not work like the original grid. What is the end goal functionality?
@SusanM I may have been lucky, but I had used UD fields in E9 in SugPODtl and all of them are available in the Material list grid, so you may not have to add them yourself, just unhide them if needed.
To populate the data fields I use a post processing bpm on POSugg.GetRowsPlant checking that the parameter whereClauseSugPoDtl contains the BuyerID for that suggestion and mark that suggestion as processed.
@gpayne I stumbled upon this old post. I’m currently trying to populate the UD fields using a post processing BPM on POSugg.GetRowsPlant. I’m having a hard time getting this to trigger (Probably because of the whereClause). Would you mind sharing how you accomplished this.
the only change I would make to @gpayne’s code is to FIRST do the query into a variable, and then do the foreach on that variable. Reason (as I have been told by others more knowledgeable than myself) is that having the query in the foreach statement leaves the database open during the entire looping process, but doing the one database access first gathers all the data into memory first, then you loop through it. (I also always format my queries like this for easier reading later when I return to debug something I did wrong… SPACE is our FRIEND!)