Skip to main content

Hello All,

I am encountering the error message, 'Error: Another process has deleted the 'SOShipLineSplit' record. Your changes will be lost.' This occurs when I click the Save button on the Shipments screen after deleting a shipment line. So far, I have observed this issue with serial-tracked items and have not yet verified it with other item types.

After investigation, I have discovered that this error is related to one of the declared views see below.

 public PXSelect<PX.Objects.SO.Table.SOShipLineSplit,
Where<PX.Objects.SO.Table.SOShipLineSplit.shipmentNbr, Equal<Optional<SOShipLine.shipmentNbr>>,
And<PX.Objects.SO.Table.SOShipLineSplit.lineNbr, Equal<Optional<SOShipLine.lineNbr>>>>>
ShipmentSplitDetails;

The PX.Objects.SO.Table.SOShipLineSplit DAC directly represents the SOShipLineSplit table from the database, without any projection attributes applied. I believe that during deletion, cascading deletions supported by the PXParent attribute are triggered twice: once for the PX.Objects.SO.SOShipLineSplit DAC and again for the PX.Objects.SO.Table.SOShipLineSplit DAC. This appears to be causing the error.

Any suggestions for resolving this issue?

On 24R1 release of Acumatica.

Hi @vardan22 

Is this your trace error?


Can you show us how you’re deleting the records?


Hi @vardan22 These issues are sometimes caused by customizations. Hence, please try after unpublishing the customizations, if any, on the Shipments and Sales orders screens.


Hi @vardan22 

Is this your trace error?

Hi @Kandy Beatty 
Please see the trace below for this error. I believe this issue is related to the PXProjection attribute. As I mentioned in the question, it appears to be triggered twice.
 

 


Can you show us how you’re deleting the records?

Hi @Django 
I am using the sample deletion scenario with the Delete button on the details grid. Please refer to the attached demonstration for further details.


Hi @vardan22 These issues are sometimes caused by customizations. Hence, please try after unpublishing the customizations, if any, on the Shipments and Sales orders screens.

Hi @ChandraM 

In the system, this error occurs even without any other customizations. It appears solely with the addition of the following view in the extension of the SOShipmentEntry graph.

 public PXSelect<PX.Objects.SO.Table.SOShipLineSplit,
Where<PX.Objects.SO.Table.SOShipLineSplit.shipmentNbr, Equal<Optional<SOShipLine.shipmentNbr>>,
And<PX.Objects.SO.Table.SOShipLineSplit.lineNbr, Equal<Optional<SOShipLine.lineNbr>>>>>
ShipmentSplitDetails;

 


HI @vardan22 

 

Do you have any packages that are packed on the shipment?

 

That could be why you’re receiving the error, the packaged line is still there and is being read from SOShipLineSplit but the line is not actually there.

 

Aleks


HI @vardan22 

 

Do you have any packages that are packed on the shipment?

 

That could be why you’re receiving the error, the packaged line is still there and is being read from SOShipLineSplit but the line is not actually there.

 

Aleks

No customizations are required in the system for this error to appear. This issue occurs upon declaring a view with the PX.Objects.SO.Table.SOShipLineSplit DAC. You can reproduce the error by opening any empty system with SalesDemo data, extending the SOShipmentEntry graph, and adding the view as shown in the question. After publishing that package, you will encounter the same issue in your system.


Hi @vardan22 

 

I think you might have misunderstood what i meant by packages, apologies, I meant the packages on the shipment.

But your answer inadvertently answers that.

 

Aleks


Thank you all for responding and helping to find a solution!

In my investigation, I found that this issue can be resolved by adding the following cache-attached event handler in the Shipment graph extension.

[PXRemoveBaseAttribute(typeof(PXParentAttribute))]
public virtual void _(Events.CacheAttached<PX.Objects.SO.Table.SOShipLineSplit.shipmentNbr> e) { }

I am not certain this is the best solution, but for now, it resolves my issue.


Hi @vardan22 

 

unfortunately, this will strip any relation between the SOShipLine and SOShipLineSplit relations, therefore you may have data inconsistency. 


Hi @vardan22 

 

unfortunately, this will strip any relation between the SOShipLine and SOShipLineSplit relations, therefore you may have data inconsistency. 

Hi @aiwan 

Thank you for your response! I share concerns about potential data inconsistency as well. The key factor for this approach to work correctly is that the Shipments entry interacts with the PX.Objects.SO.SOShipLineSplit DAC instance cache, and all data manipulations are done using PX.Objects.SO.SOShipLineSplit. Initial testing shows that it functions as expected, so I am hopeful this solution will be effective.

The issue arises because the system treats the PX.Objects.SO.Table.SOShipLineSplit and PX.Objects.SO.SOShipLineSplit DAC caches as non-identical. My assumption was that these two caches would be merged, as PX.Objects.SO.SOShipLineSplit is essentially a projection of PX.Objects.SO.Table.SOShipLineSplit.


Hi @vardan22 

 

I was revisiting your view, could you please try the following:

public SelectFrom<PX.Objects.SO.Table.SOShipLineSplit>. Where<PX.Objects.SO.Table.SOShipLineSplit.shipmentNbr.IsEqual<SOShipLine.shipmentNbr.FromCurrent>.And<PX.Objects.SO.Table.SOShipLineSplit.lineNbr.IsEqual<SOShipLine.lineNbr.FromCurrent>>>.View ShipmentSplitDetails;

I noticed in your view you weren’t specifying the Current/FromCurrent


Hi @vardan22 

 

I was revisiting your view, could you please try the following:

public SelectFrom<PX.Objects.SO.Table.SOShipLineSplit>. Where<PX.Objects.SO.Table.SOShipLineSplit.shipmentNbr.IsEqual<SOShipLine.shipmentNbr.FromCurrent>.And<PX.Objects.SO.Table.SOShipLineSplit.lineNbr.IsEqual<SOShipLine.lineNbr.FromCurrent>>>.View ShipmentSplitDetails;

I noticed in your view you weren’t specifying the Current/FromCurrent

This is also not working because, in the view declaration, I used Optional<> instead of Current.


Reply