By using this website, you agree to our Terms of Use (click here)
We are receiving this error on a shipment.
The order is being partially shipped.
It will not allow the shipment to be deleted or confirmed.
Any ideas?
I've logged a high priority with Acumatica but am awaiting a response.
Thank you.
Wendy
Never seen this before. Was Acumatica able to fix it?
Yes and here's their response.
I fixed data corruption in the order.
If the issue will appear again, I think you need to turn the field level audit on these screens. This can help to find out the root cause.
Thank you!
We actually have field level audits turned on for most of our major input screens. It definitely helps understand what is an issue with Acumatica/customization and what is user error. It is amazing how many times a user's recollection of events is corrected by looking at the audit history.
Hello Wendy,
I also faced with the "Shipment counters are corrupted" error and got the response from Acumatica support with the scripts below:
Run the detection script :
declare @companyid int = <companyid>
select [Status], Confirmed, Hold, *
from SOShipment
where companyid = @companyid and (Confirmed = 1 and [Status] in ('H','N')
or Confirmed = 0 and [Status] in ('F','Y','I','C'))
Run fix script to set correct statuses:
declare @companyid int =<companyid>
update SOShipment
set [Status] = case when Confirmed = 1 then 'F' else 'N' end,
Hold = case when Confirmed = 1 then 0 else Hold end
where companyid = @companyid and
( Confirmed = 1 and [Status] in ('H','N')
or Confirmed = 0 and [Status] in ('F','Y','I','C'))
These scripts work correctly and I managed to update my corrupted shipments with proper statuses.
Hope this will work for you as well.
I am also been getting this Error message "SO Error: Shipment counters are corrupted." We haven't processed any of the shipment yet.
What was the recommended answer?
Acumatica fixes this in the database directly. Scripts are not available for the general public.
@michaeltriffon thank you, I know that, but I strongly advice against it. It's one thing to run a detection script (above) and review the data in SQL before trying to fix it, and it's different thing to blindly fix the data when you have no access to the SQL directly. But I agree with you, if you accept a risk, you can run a SQL script by publishing a customization project.
I totally agree with you @karpenko-yuriy. Make Acumatica run the scripts and take on the liability. Make them earn the 2nd "S" in SaaS!
@karpenko-yuriy I agree it can be risky if you don't have the proper resources. Fortunately we have an SQL expert on staff who can not only write scripts, but more to this point, read one to evaluate potential issues. I understand that some may feel there may be unintended consequences but bogeyman scenarios can be avoided by not BLINDLY doing anything.
In our case, we created a local instance and restored a snapshot to it for testing purposes. It also gave us complete access to the SQL database and the snapshot served as a backup in case things went sideways. We then ran the script and checked that the affected data was corrected. Once validated we ran it on the live site.
In this particular case, it was the 2nd time this happened and we felt confident after our first go around so the script is now part of our toolbox. We also needed it done immediately because the customer was unable to confirm shipments, blocking some warehouse operations. The point is we used a thoughtful and careful approach before proceeding.
That being said, I realize not everyone is comfortable with this and wholeheartedly agree that Acumatica support should bear the responsibility for fixing it. I do not endorse anyone following our example.
Online Members
