Sage 100

UDF shown in AP invoice history inquiry shows incorrect value (Posted to SageCity... might as well share with 90-minders too!) v2017.2 Premium UDF in AP_InvoiceHistoryHeader is added to the Header panel in invoice history inquiry. A UDF of the same name exists in GL_DetailPosting, and sometimes (repeatable, but not for all invoices) an unrelated value from the GL table is displayed on the invoice history inquiry's header panel. A search of the Sage KB comes up with a similar issue, documented for AR (with no resolution in almost a year). Has anyone seen this for AP before? Is it likely to have been fixed in a more recent product update / or v2018? (Note, the customer has a couple enhancements, including AP Multi-Currency, so opening a Sage case will likely meet with some resistance accordingly and I'd like to avoid that if I can).

I ran into a similar issue when I added a udf with the same name to ci_item and im_itemwarehouse and added the ci_item udf to the item inquiry main tab. The issue is because of the way nomads and providex uses a variable in memory with a name that matches the field name. So when the warehouse quantity list box is read and the iolist variables are populated, the last record read from im_itemwarehouse would cause the variable in memory to equal what was in the im_itemwarehouse udf instead of ci_item and this would override what was displayed in the ci_item's udf field on the panel. Sage may have fixed this in later version by using a record prefix when reading values from other tables but I don't know if they have done this everywhere throughout the software.

Thanks for the excellent explanation! It makes sense... not having a full record prefix would certainly cause problems.

I know you script as well so I'm sure you have seen those variables that you can use in sales order entry to get a value from ci_item. Something like oBusObj.GetValue ""im.ItemType"", sItemType The ""im."" Is the record prefix.

Yes, I have seen that... during Alnoor's scripting class a few years ago. The parallel I draw is with a SQL query, joining tables with a common field name. Without a table prefix, SSMS will warn me about the ambiguity. With memory objects there would be no such warning.