Skip to main content
Question

Update IN action fails silently ('record cannot be saved') when triggered programmatically, due to unanswerable Shipped-Not-Invoiced confirmation prompt

  • September 29, 2026
  • 2 replies
  • 35 views

Acumatica version: 2026 R1, build 26.100.0175.5

Issue:
When the SO Order Type has "Use Shipped-Not-Invoiced Account" unchecked (no account configured), pressing Update IN interactively (via UI) correctly shows a confirmation dialog:

"The shipped-not-invoiced account is not used. On the subsequent invoice, revenue might be posted to a different financial period not matching the COGS period. Update IN?"

However, when Update IN is triggered programmatically - either via a custom graph extension calling updateIN.Press(), or via a Business Event/Import Scenario mapped to the Update IN action - there is no way for this confirmation to be answered. The action fails with a generic wrapped exception:

"Error: The record cannot be saved."

surfacing through PX.BusinessProcess.Event.ManualEventProcessor.TriggerActionEvents -> PXActionCollection.PressSave -> PXWorkflowService.CompleteOperationInternal -> PXGraph.Persist(), with no indication in the exception message or trace that an unanswered confirmation dialog is the actual cause. We only identified the true cause by checking Business Events history, which logged:

"0 records of 1 have been processed. The last error was The shipped-not-invoiced account is not used..."

This took significant time to trace because the generic exception gives no hint that an interactive confirmation is the blocker, and it reproduces identically regardless of what triggers the automated Update IN call (custom code, Business Events Import Scenario, etc.) - initially appearing as a code or Business Event configuration issue, when the actual cause was this GL setup gap.

Questions:
1. Is there a way to programmatically pre-answer or suppress this specific confirmation (similar to how some Persist()/RowPersisting exceptions can be caught and auto-confirmed via PXException.Answer or similar mechanisms) without enabling the Shipped-Not-Invoiced account?
2. Is this expected behavior for any interactive confirmation dialog encountered during a programmatically-triggered action (i.e., should we expect this pattern elsewhere), or is this specific to Update IN?
3. Could the exception message be improved in a future update to surface the actual underlying reason (the unanswered confirmation) rather than the generic "record cannot be saved," to help others diagnose this faster?

Happy to provide full stack traces and reproduction steps if helpful.
 

 

2 replies

Captain II
Forum|alt.badge.img+4

​@bhavyasreegedipuri73 Please find the below Aguform Reference, that one is for a different scenario but same method should work for you scenario as well.

https://www.augforums.com/forums/everything-else/using-an-import-scenario-to-change-the-item-class-on-a-stock-item/

🚀If I have helped you, "Like" my post. If it solves it mark "Best Answer". 🚀
    Steve Milner
    Varsity III
    Forum|alt.badge.img+4
    • Steve Milner
    • Varsity III
    • September 30, 2026

    @bhavyasreegedipuri73 The link Ranjith posted is the right pattern for the scenario side: the <Dialog Answer> row goes before the step that raises the prompt, on the summary object. For Update IN that means a <Dialog Answer> row on the Shipment Summary object with the value ='Yes', directly above the Update IN action row.

    In your graph extension it's the same idea in code. Store the answer before you press the action:

    Base.Document.View.Answer = WebDialogResult.Yes;
    Base.GetExtension<UpdateInventoryExtension>().updateIN.Press();

    On your second question, yes, expect it elsewhere. The prompt comes from View.Ask on the shipment's Document view. When no answer is stored for that view, Ask throws a PXDialogRequiredException. On the screen that becomes the Yes/No box. Anywhere else it's just an exception, and its message is the text your Business Events history logged. Any action that asks Yes/No behaves the same way unless its code checks UnattendedMode first. Update IN does check it, but import scenarios create the graph with UnattendedMode off, so the prompt still fires there. The fix is always to store the answer on the view that asks.

    The check is also skipped when Use Shipment Date for Invoice Date is selected on Sales Orders Preferences (SO101000). That changes how every invoice gets dated, so only go that way if your client wants it anyway.

    Answering Yes means every automated Update IN posts without that warning, so test it on a copy of the tenant first.

    A clearer error message would be a product change, so it's worth posting in the Ideas section.

    Steve Milner - Acumatica Consultant, Acumaven Inc. | acumaveninc.com | linkedin.com/in/steve-milner-52654b3
    Terms & ConditionsAccessibility statement
    About Acumatica ERP system
    Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
    © 2008 — 2024  Acumatica, Inc. All rights reserved