InvcHead (has UD fields) vs InvcList (no UD fields)

Migrating from E9, we have a customization that is referencing a UD field in the InvcHeadList dataview. The UD field doesn’t exist in InvcHeadList and I’m wondering how to get around this.

In InitializeCustomCode() we have:
edvInvcHeadList.dataView.Table.Columns[“Number01”].ExtendedProperties[“Format”] = “>>>>>>>>9”;
but because Number01 doesn’t exist, we get the Null reference error.

This does not give an error:
edvInvcHead.dataView.Table.Columns[“Number01”].ExtendedProperties[“Format”] = “>>>>>>>>9”;

Thanks!

Do you have to go after the List view and not the Head view? In E9 the extended fields were part of the table whereas in E10 they’re in a separate UD table (I think, it’s been a while since we were on E9). The native views like edvInvcHead in E10 will automatically join the table and the UD table, but typically list views are a trimmed down version, and in this case I’m guessing it’s just going after the table without joining in the UD table.

Thanks for your response, Aaron.

I thought so as we are dealing with a the invoice list at the Group tab. Is there a method to add a ud field to the list dataview or is there another way to handle this? Thanks!

Since that is a native view, I do not know of a method to do add a field to it without causing a lot of headache. You could consider creating your own EpiDataView and tying it to the results of a BAQ, wherein you could join the UD table to the native table, but at that point you might as well use the InvcHead view.

Is there a reason you can’t use InvcHead?

I don’t know. I thought that since it was being used in a grid that I needed the list, but I’m guessing that’s not the case?

No way for me to tell what it’s being used for from the info I have, but it looks like you’re just formatting the data to trim decimals. If you just comment out the listview extended properties from that extended field (number01), I think you’ll see that it works and that the number01 will be formatted wherever it’s bound to the InvcHead view. I’m curious what edvInvcHeadList is bound to, hmm

It just so happens that I realize that I don’t even need this functionality anymore, so I’m not going to pursue this further at this time, but I may be coming back around if I run into this again on another form.

Can you just clarify for me when/why I might want to use the HeadList instead of Head? If never, why does it exist?

Thanks!

It looks like the InvcHeadList dataview is used to power that initial grid on AR Invoice Entry. Choosing the right dataview to hook onto for customization is really up to the requirement. In this case, I’d say there is no difference other than the lack of UD fields, so I’d go after the edvInvcHead if I needed that to fulfill my requirement.

Epicor changed the behaviour in E10 because when GetList and GetRows both got the same data it hit performance… So by keeping “List” slim to Essential Columns, they improved alot of performance.

So yes, you will have to change the EpiBinding to InvcHead instead of InvcHeadList - Looks like in that form they decided to use the same EpiBinding they use on the Navigation Control all the way up.

If you are a developer and want to read about .GetList / .GetRows:

Thanks, Aaron! You’ve been very helpful!

Thanks, Haso (?)! That’s great info.