How to save variables from summary view to a process model

Hi! I have two records with different record actions in separated process models (create purchase order vs create invoice). In this case, I would like to be able to initiate the process of invoice creation based on the purchase order data (id, supplier, and other data passed automatically to the create invoice interface)

My trouble here is that I need to do this from the summary view for each purchase order ID (until now I had a different action in each record view).  I was thinking about creating a button in the summary view, but I don´t know how to pass the variables in a correct way or the best practice here. Which options do you recommend? Creating a button and link it to the proccess model to create the invoice? Create a related action?

My process steps would be something like this:

1) User clicks in the summary view of the purchase order

2) In the summary view, there should appear a button to make an invoice with the PO data

3) The data collected should flow to the user input task to create a new invoice. Until now, I was filling the interface text fields manually

My process model to create the invoice starts with the "Create New Invoice" interface, so I´m not sure about how to connect the data in this case:

Any help would be useful. Thanks a lot!

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer

    If you'd like the user to be able to click something and flow directly to a subsequent task (similar to how a Related Action works), but for arbitrary data, then you might like to use a!startProcessLink() in your grid in your top screenshot.  Note that this would cause the user to leave the summary view for all intents and purposes and see something else until they complete the process chain, then after that they'd be returned to where they started (plus or minus any changes effected by reloading of that interface after any changes have been saved).

    Another technique I've used in cases like this, geared more towards wanting a user to initiate background processes for items in a grid, is a!startProcess(), which launches an asynchronous process instance without interrupting the user's current view.  This approach would be more useful for when you want some processing to happen in the background and/or a task to be assigned (either to the acting user or to an unrelated user/group).

    The above two options each have their own pros / cons, but you'll need to decide on one approach and gear your overall solution to use it (of course before you decide it's easy to *try* both).

  • 0
    Certified Lead Developer

    Why not just add a record action to the PO record. In the record action config, you can pass any data you need to the process variables which will then be populated in the interface.

  • Thanks both! I decided to start creating a new record action, and putting a record action component in my summary view interface. Now, it looks like this:

    1) Summary view interface for each PO id

    In this case, I used the record action component and selected the new created action, to which I assigned a similar process model (to create the invoice)

    Also, I checked that the information is correctly saved in the rule input of the summary view

    2) Connecting to the interface to "Create the invoice"

    In this case, when I click the record action component shown previously ("Facturar Pedido), the following interface appears:

    I want to link the rule input values of the summary view interface to this creating invoice interfaces, for the fileds IdPedido and Proveedor to be filled automatically (in this case, based on the rule input shown, the values would be IdPedido=1 and Proveedor=Proveedor 1). Now the information is not flowing between interfaces, and I have some doubts:

    - Do you think my approach using a record action component is correct? Should I make any changes?

    - Which is the best way to connect the ri!record from the first interface to the second one? Which values should have the text components of the second interface to adquire the values of the other interfaces values?

    - Do I need to pass the first interface as an start form in the process model? When I tried doing it, it seemed to me that it was unnecessary, everyting was like duplicating. I think that putting the record action component is enough, but I want to be sure

    Thanks a lot!

  • 0
    Certified Lead Developer
    in reply to carlosp5114

    A record action is the right way, but you need to wrap your head around how they work.

    A record action is always initiated in the context of a specific record item. In your case the PO. In the record action field, you only pass the ID of the selected record. No other data is "flowing" into that action when started. All the data that you might need in record action's process or UI has to be loaded in the record action configuration in the record editor.

  • I have created a related record action for the PO order (using as a model the update action) and then changing the process model to use this initial interface to create the invoice (rows generated in the other record, invoices). In this case, the PO fields are passed correctly from the PO records and saved into the invoice record.

    The fact is that, also, I have to fill fields of the other record (invoices) manually. Even though in the process model and in the interface I can write them correctly and are saved, when I try to write manually in my site the value is erased after I click in another text component:

    Fields erased after clicking:

    Interface configuration (manual fields of Campos Factura are saved into the recordFact and remain there instead of being erased)

    *Note: in this summary I´m mixing two record types. I don´t know if a related record action from one record casues any trouble if I create rows in another different record. 

    What can I do?

  • 0
    Certified Lead Developer
    in reply to carlosp5114

    Fields not storing their value typically is caused by a rule input not assigned to a process variable, or the process variable is not configured as a parameter.

    Everything else is hard to say .... hard to follow what you want and what actually happens.