@ppowell there are a few elements to consider for this request.

I don’t believe it’s possible to alter those fields programatically or get the screen to remember what they were set to.

This is not quite right. You could achieve this by extending the header’s DAC filter and adding those fields. For instance, adding a checkbox as follows:

  public class VendorLocationExt : PXCacheExtension<PX.Objects.PO.VendorLocation>
  {
    #region DefaultFilter
     PXBool()]
     PXUIField(DisplayName="Default Filter")]
     PXDefault(true, PersistingCheck = PXPersistingCheck.Nothing)]
    public virtual bool? DefaultFilter { get; set; }
    public abstract class defaultFilter : PX.Data.BQL.BqlString.Field<defaultFilter> { }
    #endregion
  }

And that DAC extension could then get added to the header.

Reviewing the original graph, we can see that the grid’s content is driven by the VendorCatalogue data view. And in this case, you have the advantage that there is not a native delegate associated to that view - which simplifies the redefinition of the view

In a graph extension then, you could redefine the data view as:

        "PXImport(typeof(VendorLocation))]
        public POVendorInventorySelect<POVendorInventory,
            LeftJoin<InventoryItem, On<POVendorInventory.FK.InventoryItem>,
            LeftJoin<Vendor, On<Vendor.bAccountID, Equal<POVendorInventory.vendorID>>,
            LeftJoin<Location,
                        On<Location.bAccountID, Equal<POVendorInventory.vendorID>,
                        And<Location.locationID, Equal<POVendorInventory.vendorLocationID>>>>>>,
            Where<POVendorInventory.vendorID, Equal<Current<VendorLocation.bAccountID>>,
            And2<Where<POVendorInventory.vendorLocationID, Equal<Current<VendorLocation.locationID>>,
            Or<POVendorInventory.vendorLocationID, IsNull>>,
            And<
                Where<InventoryItem.itemStatus, Equal<INItemStatus.active>>>>>,
            VendorLocation> VendorCatalogue;

Notice that this condition is being added:

InventoryItem.itemStatus, Equal<INItemStatus.active>

And as a result, only the active items will be listed.

Adding the IsDefault filter however is proving to be a bit more complicated.
The field is an unbounded DAC calculated at runtime:

		#region IsDefault
		public abstract class isDefault : PX.Data.BQL.BqlBool.Field<isDefault> { }
		protected Boolean? _IsDefault;
		tPXBool()]
		)PXUIField(DisplayName = "Default", Enabled=false)]
		)PXDependsOnFields(typeof(POVendorInventory.inventoryID), typeof(POVendorInventory.vendorID), typeof(POVendorInventory.vendorLocationID))]
		)PODefaultVendor(typeof(POVendorInventory.inventoryID), typeof(POVendorInventory.vendorID), typeof(POVendorInventory.vendorLocationID))]

And the problem that this appears to be causing is that the redefinition of the Data view does not find a bounded field in the DB:

Data view filter:

                Where<POVendorInventory.isDefault, Equal<Current<VendorLocationExt.defaultFilter>>,
                    Or<Current<VendorLocationExt.defaultFilter>, IsNull>>>>>,

SQL profiler result:

AND ( NULL = CONVERT (BIT, 1) OR @P2 IS NULL ))

Notice the left side of the filter is shown as NULL as opposed to a DB field.

It would appear then that unbounded DAC fields are considered in the logic AFTER the SQL script is run.

I am attaching the customization package as reference. Potentially you could resolve this limitation by defining a delegate for the Data view and managing the IsDefault filter within it

Hi @Fernando Amadoz,

Thanks for this, it was really helpful.  I decided to forget adding extra fields and have used your example to limit the screen to just showing active items instead.  I wasn't able to filter by IsDefault but as a compromise I set the column to sort descending so the checked ones appear at the top.  The user is happy with this solution.

Thanks again, I really appreciate it.

Phil