Custom workflow state not reached on UpdateIN in SO Shipment Workflow

Question

Currently, I’m using Acumatica 2026 R1. I’m adding a custom state in SO Shipments SO302000 (state name : Transferred) that is supposed to be processed through the UpdateIN action.

What I did :

Created a customization project with an extended workflow for SO302000 (inheriting the default workflow).
Modify a transition from Confirmed with Triggered By Action = Update IN (updateIN), to target my state. (Replaced Completed with Transferred)
Published the project.

What happens :

The action executes normally, but the shipment still ends up in Completed. My transition never fires.

What I found in the source :

UpdateInventoryExtension.UpdateIN fires, then runs the real work inside PXLongOperation.StartOperation on a new SOShipmentEntry instance. Inside PostShipment:

using (PXTransactionScope ts = new PXTransactionScope())
{
	SetSuppressWorkflowOnUpdateIN();

	foreach (var args in GetPostShipmentArgs(shiporder, docgraph, list))
	{
		PostShipment(args);
	}
	ts.Complete();
}

and inside PostShipment(PostShipmentArgs) calls method UpdateStatusOnPostShipment(SOShipment shipment) that assign the status directly:

protected virtual void UpdateStatusOnPostShipment(SOShipment shipment)
{
    if (shipment.UnbilledOrderCntr == 0 &&
        shipment.BilledOrderCntr == 0 &&
        shipment.ReleasedOrderCntr == 0 &&
        shipment.Released == true)
    {
        shipment.Status = SOShipmentStatus.Completed;
    }
}

My conclusion is that the workflow engine is suppressed for the whole scope, the status is written in code, and what the UI shows afterwards is just the record re-read by actualizeRecordBy. So no editor-defined transition on this action can ever take effect.

Questions

Is that conclusion correct, or is there a supported way to make an action-triggered transition fire on Update IN?

Any pointers appreciated!

Rakshanda · Accepted Answer

Hi @andresetiawan,Your conclusion is correct. The workflow engine is explicitly suppressed via SetSuppressWorkflowOnUpdateIN(), and the status is then hard-coded in UpdateStatusOnPostShipment. No workflow transition you define on the updateIN action will ever fire.Your options1. Override UpdateStatusOnPostShipment — It's a protected virtual method, so you can override it in a graph extension of the appropriate level on SOShipmentEntry (or whichever graph contains it) and set your custom status instead of/after SOShipmentStatus.Completed.Recommended approach: option 1public class SOShipmentEntry_Extension : PXGraphExtension{ [PXOverride] public virtual void UpdateStatusOnPostShipment(SOShipment shipment, Action baseMethod) { baseMethod(shipment); // After base sets Completed, override to your custom status if (shipment.Status == SOShipmentStatus.Completed) { shipment.Status = YourCustomStatus.Transferred; } }}2. Use a RowPersisted or RowUpdated handler — After the status is set to Completed but before/after persist, swap it to your custom status.Hope above helps!!

FarhanaM60 · Answer

After digging into the source, I noticed that Update IN is implemented in UpdateInventoryExtension.cs. The action runs inside PXLongOperation.StartOperation() on a new SOShipmentEntry instance, and during posting it eventually calls UpdateStatusOnPostShipment(), which directly sets:

shipment.Status = SOShipmentStatus.Completed;

It also appears that workflow is suppressed during this process (SetSuppressWorkflowOnUpdateIN()), so my custom workflow transition (Update IN → Transferred) never gets a chance to execute, and the shipment is saved as Completed.

Is my understanding correct that Update IN bypasses workflow transitions by design? If so, is the supported approach to customize/override the logic in UpdateInventoryExtension (or UpdateStatusOnPostShipment) if a different status is required after posting, rather than relying on a workflow transition?

Sign up

Social Login

Login to the community

Social Login