The APApproveBills graph has a data view and a data view delegate, but according to the above articles, it seems like the following code should achieve what I need:
namespace PX.Objects.AP { public class APApproveBills_Extension : PXGraphExtension<PX.Objects.AP.APApproveBills> { public override void Initialize() { Base.APDocumentList.OrderByNew<OrderBy<Vendor.acctName.Asc>>(); } } }
This does change the sort, but the result is not what I am expecting.
Can someone explain why this is happening and/or how to fix it?
Page 1 / 1
@darylbowman when you have Delegate, it overrides all predecessors which includes initialization.
you will need to override the delegate. If you didn’t have Delegate then initialization override would do the work.
I suspected this may be the case. So I overrode the data view and delegate like this, including copying a private method (not shown) which actually returns the data, like this (summary below):
namespace PX.Objects.AP { public class APApproveBills_Extension : PXGraphExtension<APApproveBills> { PXFilterable] public PXSelect<APInvoice> APDocumentList;
which I believe should completely change the sort. Yet, the result is the same as simply changing the sort in the Initialize method, which is fantastically easier, but the result is still incorrect.
Have I done this wrong in some way?
@Nayan Mansinha@slesin
@darylbowman AFAIK, you will need to override the delegate if it’s originally defined in the main logic (as you are doing it), but it will be the actual Data view’s orderby the one that will define the order.
So try this:
Remove the logic from the Initialize() method.
Define your overridden data view + delegate like this:
rPXFilterable] public PXSelectOrderBy<APInvoice, OrderBy<Asc<APInvoice.vyourSortField]>>> APDocumentList;
Unfortunately, the result is the same. The sort is applied in some way, but not like I would expect:
Hi guys,
The view “APDocumentList” doesn’t use Vendor table:
fix in graph extension:
public class APApproveBillsExt : PXGraphExtension<PX.Objects.AP.APApproveBills> { public static bool IsActive() => true;
PXFilterable] public SelectFrom<APInvoice>.InnerJoin<BAccount>.On<APInvoice.vendorID.IsEqual<BAccount.bAccountID>>.OrderBy<BAccount.acctName.Asc>.View APDocumentList;
}
Result on my local Sales Demo DB:
I guess this makes sense. Vendor is joined in the data view delegate, which I guess is why I thought I would be able to do that.
I tried it, with the data view delegate also defined, and the result was the same:
I realized that you hadn’t mentioned the data view delegate, so I removed that and tried again. It sorted the list fantastically. However, without the data view delegate, the whole APInvoice table is returned, which is not correct. The data view delegate is necessary to return the correct results.
So yet one more way to get a very close (and obviously working), but not correct result.
Also, since the result is exactly the same as my original attempt, it stands to reason that you can actually sort by tables that are not explicitly joined in the data view.
Bump
This behavior is also present in 23.102
I was able to get this accomplished through a DAC extension adding the Vendor.AcctCD to the APInvoice, and then using your initial idea to sort by that new field. It works with the filters!
public class APInvoiceApproveBillsExt : PXCacheExtension<APInvoice> {
#region UsrVendorCD PXString] PXFormula(typeof(Selector<APInvoice.vendorID, Vendor.acctCD>))] PXUIField(DisplayName = "Vendor")] public virtual String UsrVendorCD { get; set; } public abstract class usrVendorCD : PX.Data.BQL.BqlString.Field<usrVendorCD> { } #endregion } public class APApproveBillsExt : PXGraphExtension<APApproveBills> { public override void Initialize() { Base.APDocumentList.OrderByNew<OrderBy<APInvoiceApproveBillsExt.usrVendorCD.Asc>>(); } }
Fantastically simple solution that I would not have thought of otherwise. Thank you!
Thank you for sharing your solution with the community @Keith Richardson