Solved

Base.Save.Press() Method Behavior

  • 24 August 2023
  • 3 replies
  • 169 views
R
Rank
Userlevel 4
Badge +1

Hello,

I have an action that I would like to run as a process on a sales order. It’s really an ‘initialize’ action where I can do some validation while I save it. I have simplified the code to the base where I’m still getting the same behavior. Ultimately, I want to persist the record before I do any processing due to the way the system caches data on the tables/items I’m running calcs on. Can anyone tell me why when I execute this action (before initially saving) the system redirects me to a blank sales order? In order to find it again, I have to press the “Last” button to get back into it. 

        public PXAction<SOOrder> Test;

        [PXProcessButton(CommitChanges = true, Category = "Processing", Connotation = PX.Data.WorkflowAPI.ActionConnotation.Success)]
        [PXUIField(DisplayName = "Test")]
        protected IEnumerable test(PXAdapter adapter)
        {
           Base.Save.Press();

           return adapter.Get();
        }

Alternatively, if I save manually before pressing the button, I have no issues and it keeps me on the same order. 

I really just want to know if there is something I’m missing on the setup and if not, what people do to ‘hide’ these types of buttons to force someone to save it before the system will let them execute. I’m even willing to consider a row selected event handler to hide the action until some field has been initialized.. but I’m not sure which field that would be.

Thanks in advance!

icon

Best answer by Dmitrii Naumov 24 August 2023, 13:32

View original

3 replies

S
Rank
Userlevel 7
Badge +10

Hi @rhooper91 ,

Could you please try below code snippet?

public PXAction<SOOrder> Test;

        [PXProcessButton(CommitChanges = true, Category = "Processing", Connotation = PX.Data.WorkflowAPI.ActionConnotation.Success)]
        [PXUIField(DisplayName = "Test")]
        protected IEnumerable test(PXAdapter adapter)
        {
           Base.Save.Press();
           SOOrder order = Base.CurrentDocument.Select();

             // Perform your validation and processing logic here
             if (order != null)
               {
                  // Your validation and processing logic
               }

           return adapter.Get();
        }

I believe, the issue you're encountering seems to be linked to the way Acumatica manages unsaved changes. When you click your "Test" button without having saved the record first, Acumatica tries to save the modifications due to the "Commit Changes = true" setting. However, because it lacks clear instructions about where to go next, it might redirect you to an empty sales order.

Hope, it helps!

Regards,

Sweta

Dmitrii Naumov
Rank
Userlevel 7
Badge +5

@rhooper91 You get this behavior because of the return adapter.Get();

The line redirects you to the document that is referenced in the adapter, which is OrderType=”SO”, OrderNbr=”<NEW>”. You can check Searches filed value in the adapter.

 

However, the document you are working on is not <NEW> anymore after the save. It has a real number. So this line redirects you to the new document instead.

 

To avoid that you can do something like  that:

 

protected IEnumerable test(PXAdapter adapter)
{

Base.Save.Press();

return new List<SOOrder>() {Base.Document.Current};

}

 

However, I do not think the workflow you describe (with saving something to the DB during Initialization) is a good approach. 

R
Rank
Userlevel 4
Badge +1

@sweta68 - Thank you for your response!

@Dmitrii Naumov -

This worked, thank you! I figured it had something to do with the order number. While I agree that I don’t like processing this logic in this way, it is due to how the system calculates item availability. I’m trying to be able to validate if there is enough qty to satisfy the order and plug that as a boolean on the line. The reason why I have to persist is because the system availability calcs can change whether the recent changes are persisted or not (especially with allocations on split lines)- to alleviate headaches and potential errors in calculation, I chose to just persist everything first and then I can calculate it the same way every time.

See below for flow diagram:

Can you please advise why you don’t suggest it in this case and perhaps, what an alternative might be? I can start a new thread and tag you, but I really would like to get insight from you on this in case there are more deeper seeded issues with the way I’m approaching this.

Perhaps even hiding the button until it has been initialized could be an approach- but I’m not sure how to evaluate if it has been initialized and saved or not.

Thanks!

Reply


Terms & ConditionsCookie settings
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