Override SOShipmentEntry data view

Hi ​@benb1977 

To override a data view with a data view delegate, you need to create a method with the same name as the view but starting with a lowercase letter. So your method in the graph extension should be named shipmentScheduleSelect.
Additionally, do not specify any parameters in this method — parameters for the BQL query should be defined inside the data view delegate itself.

So in the end, your data view delegate should look as follows:

public virtual IEnumerable shipmentScheduleSelect()
{

}

Hi ​@benb1977 

If you want to override a view, you need to follow these steps:
1.  Create the graph extension
2.  Find and copy the data view declaration
3. Paste the data view declaration in the graph extension
4. In the graph extension redefine the data view declaration as required.

The data view redefined within a BLC extension completely replaces the base data view within the Views collection of a graph instance, including all attributes attached to the data view declared within the base graph.

https://help.acumatica.com/(W(29))/Help?ScreenId=ShowWiki&pageid=5312e75a-6f0a-4b2c-a28c-38da20782087

Data View Delegates it is a dynamic query, which is an optional graph method .  They're used to dynamically modify query results based on parameters ( filter).

In your case, the data view delegate name must start with a lowercase letter, but it's starting with a capital letter. This could very well be the reason why this data view delegate isn't being triggered.
https://help.acumatica.com/(W(33))/Help?ScreenId=ShowWiki&pageid=acecfa2b-90d5-475c-8cf2-b2c5f8e60672

Try simply overriding the  Data View first, as a starting point.
Or describe your task in a bit more detail - that way we can find the most optimal solution

Hi again all,

Late last night I finally got this working. If you’re interested, grab a coffee because this will be a long post.

Firstly, I should be a bit more specific about what I’m trying to achieve. Several customers wish to be able to set a scheduled shipment date but still be free to ship before that date. That is currently prohibited due to this line in the data view SOShipmentEntry.ShipmentScheduleSelect:

And<SOShipmentPlan.planDate, LessEqual<Optional<SOOrderFilter.endDate>>,

The simplest apparent solution would be to define a graph extension for SOShipmentEntry and redefine the ShipmentScheduleSelect data view in the extension, removing this line checking the shipment plan date. This didn’t work though - the data view in the base graph was still the one being run. The reason for this seems to be that, while a data view override in a graph extension replaces the base data view in the ‘Views’ collection of the graph, it doesn’t touch any of the detail in the base data view itself. So, when the code shown below in SOShipmentEntry.CreateShipment runs, the data view override is not touched:

ShipmentScheduleSelect.Select(args.SiteID, endDate, order.OrderType, order.OrderNbr, args.OrderLineNbr, args.OrderLineNbr, operation)

This only accesses the base data view. So, the next step seemed to be to define a data view delegate in the graph extension. I did this, defining parameters for the data view delegate - because how else do we access the values passed into the ‘Select’ call above? I defined the same number of parameters for the delegate as the number of parameters in the base data view. Inside the delegate, a new data view would be defined that omitted the planDate condition and the date parameter passed into the delegate would be ignored.

Sadly though, even this did not seem to work. The delegate was run, but upon debugging, I found that the parameter values being passed in were all ‘null’. Some pretty serious debugging netted me the following information about the ‘Optional<Field>’ and 'Required<Field>’ parameters in the BQL for the base data view. These parameters are not defined as ‘arguments’ (PX.Data.ParameterBase<Field>.IsArgument is set to ‘false’). This means that any values passed into the Select call are not transferred to the delegate. The ‘Argument<Type>’ parameter needs to be used to get parameter values transferred to the delegate.

So the next step then, was to going back to redefine the data view in the graph extension, while keeping the delegate. But as I learned above, the data view override would not be hit. I searched through the code for possible answers, coming across an attribute named ‘PXViewExtension’ that seemed promising, but which didn’t give me any results (I’m still not 100% sure what it does). I finally found a solution by defining ‘Initialize()’ in the graph extension and replacing the PXView object of the base data view with the PXView object of the overriden data view:

public override void Initialize()
{
    Base.ShipmentScheduleSelect.View = ShipmentScheduleSelect.View;
}

There was one more surprise in store for me though - even though this allowed the delegate to access the correct parameter values, the BQL still didn’t return the desired results. I had to convert the ‘Argument’ parameters to ‘@P’ parameters.

This finally got everything working as desired. It was a long slog, but I learned a lot about the Acumatica customisation framework - knowledge that will be very useful in future. Including the fact that delegate names don’t actually need to start with a lowercase character - they just need to be equal - ignoring case - to the base data view name, and of course unique within the extension class.

Hopefully this post will be helpful for others, and to that end, I have attached to this post the code for my graph extension. Please let me know if you have any questions or see any shortcomings.

Cheers,

Ben.