Skip to main content

Has anyone had any luck in customising Shipment fields to allow editing after shipment confirmation?

Our company requires multiple shipments (one for each vehicle) against the same order. Due to Acumatica limitations, this means we need to confirm the earlier shipment to open a subsequent one, despite the shipment not actually being confirmed. Naturally, this leads to errors, which are particularly difficult to correct due to too many subsequent shipments having been ‘confirmed’ already.

This leads to the issue of how to rectify errors. Should there be any way to customise the editing of Shipment fields (such as date, description, UDFs, and quantity) even in a Confirmed state, it would help a lot to resolve our problem.

Thanks!

@kokjietan Acumatica system will allow us to edit the fields even after confirming the shipment with the below small changes.

Here is the article, will work for both Acumatica native, custom fields, and UDF fields as well.

But, as you wanted to edit the Qtys and all, please check the impacts as well and move forward.

https://asiablog.acumatica.com/2021/10/enable-customization-fields-when-document-is-completed.html

Hope this helps!!


Hi @kokjietan , Have you had a chance to see if the Blanket Order functionality (added in 2022 R1) might be helpful for this scenario? The Blanket Order would match the customer’s actual PO. The Child Orders (releases from the blanket) would be each individual shipment, and one Acumatica Shipment would be created for each child order. The child orders are linked to the blanket order so you would have traceability.  

Hope this helps,


Hi @kokjietan  Yes, it will work for the Shipments as well.


@kokjietan Can you please share the customization package, that you deployed in the local instance. I can make the changes and reshare with you 

 


Hi @kokjietan  I have modified the code and now custom fields and UDF fields got enabled when Shipment is in CONFIRMED status as well.

Please find the screenshots and attached package for your reference.

 


I know this was already answered but if you ever need a “super user” editor that you want to restrict access to, I have a suggestion.  I’ve had to do this with payments, sales orders and credit card transactions. 

Ideally you never want to be in a position where you need to go around the business logic.  Unfortunately, sometimes people find creative ways to break things or problems with third party systems leaves Acumatica records in an inconsistent state.  

The main thing you need to do is create a new graph and implement the bare minimum in terms of business logic.  If you add only the Selects necessary to load the record you want to edit (and any related records), you have nearly complete control over what you can change. 

Of course, this requires a little customization experience, and you have to be comfortable with creating a new screen and a new graph.  Given the minimalist nature of the graph you want to create, that’ll be the easy part.

The new screen you create should control exactly how much you can change.  You should keep things disabled when you know they should not be altered. 

Here is an example of the graph I have that lets me edit sales orders, line items and shipments.  I’m using FBQL to get the records in this example, but you can use whatever select mechanism suits your fancy:

using System;

using PX.Data;

using PX.Data.BQL.Fluent;

using PX.Objects.SO;

namespace SomeNameSpace

{

    public class SOOrderFixMaint : PXGraph<SOOrderFixMaint>

    {

        public PXSave<SOOrder> Save;

        public PXCancel<SOOrder> Cancel;

        public SelectFrom<SOOrder>.View SOOrder;


        public SelectFrom<SOShipment>

            .LeftJoin<SOOrderShipment>

            .On<SOOrderShipment.shipmentNbr.IsEqual<SOShipment.shipmentNbr>.And<SOOrderShipment.shipmentType.IsEqual<SOShipment.shipmentType>>>

            .Where<SOOrderShipment.orderType.IsEqual<SOOrder.orderType.FromCurrent>

                .And<SOOrderShipment.orderNbr.IsEqual<SOOrder.orderNbr.FromCurrent>>>

            .View.ReadOnly SOShipments;


        public SelectFrom<SOLine>.Where<SOLine.orderType.IsEqual<SOOrder.orderType.FromCurrent>.And<SOLine.orderNbr.IsEqual<SOOrder.orderNbr.FromCurrent>>>.View SOLines;

    }

}

 

That graph allowed me to create this screen:

 

While my screen allows changing certain fields on the sales order and line items, you can see in my FBQL that I brought shipments in as read only.  That was a conscious choice for this screen.  We haven’t had much cause to edit shipments because most of our problems start at the SO. Also, not everything is on this screen, that is also on purpose.  I only put fields on the screen that I’ve had a reason to edit in order to fix something that got messed up.

Obviously your use case is different.  However, making information available about the shipment’s sales order on your “Shipment Fixer” screen can be useful even if you don’t want it to make changes to that related item.

This particular screen came in handy when we had to start collecting sales tax and our giant stock item catalog could not easily be updated so all of the tax categories were correct (we have over 650K items).  Shipments would get stuck between confirmation and prepare invoice until the sales order line item’s tax category was fixed.

The standard warning from Spiderman’s uncle applies to using screens like this.  With great power and all that.   Two people in my company have access this and I’m one of them.  

If you’re not self-hosted, you may want to check with your hosting partner to make sure this isn’t violating any of their rules.  I don’t know if that is a thing in general but better to be safe.


@Naveen Boga - Extremely grateful for the help!

These forums tend to be a more useful resource than our local partner themselves, and people like you play an invaluable part in that. You have our many thanks.


@kokjietan Most welcome !! I’m glad that I helped you with this requirement.  


Hi @Naveen Boga, thanks for the article. The article appears to be for amending Completed Sales Orders - can I ask if the same will work for Shipments as well?


Hi @Naveen Boga ,

Regretfully, our VAR has claimed that the changing non-custom fields (eg. native & UDFs) are not possible, although we have sent them your link as guidance. Hence, we are currently trying to implement the changes ourselves, despite our limited programming background.

Would it be alright if you gave us a few pointers on how the code would look like at the Shipment level (as opposed to the SO Line level in your example)? I assume it would be placed under the Customize Business Logic screen.

Really appreciative of you lending your time thusfar on this issue.


Current code for reference, currently adding directly into Customize Business Processes under SOShipment screen.

namespace PX.Objects.SO
{

public class SOShipmentEntryExt : PXGraphExtension<SOShipmentEntry>
{
protected virtual void SOShipment_RowSelected(PXCache cache, PXRowSelectedEventArgs e, PXRowSelected InvokeBaseHandler)
{
InvokeBaseHandler?.Invoke(cache, e);
SOShipment row = e.Row as SOShipment;
if (row != null)
{
Base.Document.Cache.AllowUpdate = true;
PXUIFieldAttribute.SetEnabled<SOShipmentExt.ShipmentDesc>(cache, row, true);
}
}
}
}

Error:

\App_RuntimeCode\SOShipmentEntry.cs(55): error CS0246: The type or namespace name 'SOShipmentExt' could not be found (are you missing a using directive or an assembly reference?)

One point worth noting is the site is being hosted remotely, so we don’t have access to the local website.


Hi @Naveen Boga, here is the local package I was testing at (workflow + customised business logic) . Really appreciating your help so far. 


Hi @kokjietan Thanks for sharing the package, I will check this from my side and let you know.


Reply