You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Forms: How can I assign a task to multiple users in a table for invoice coding?

Forms
Updated May 23, 2023
posted on May 23, 2023

Scenario:

Invoices from vendors such as communication services (cell phone bills), delivery services (Fed Ex, DHL, etc.) are often shown with a total due and then line items for individual users and/or departments.

I would like to process these invoices via LF Forms by having an AP clerk start the Forms process, attach the invoice, then add multiple users to a table.  I would then like the form to route to each user in the table so they can code their portion of the invoice with their GL account information.  

Once all users have coded their GL accounts and amounts, show the total at the bottom of the form to ensure it matches the invoice amount originally entered by the AP clerk, and then route back to AP for completion.

What is the best way to do this?  Would it be possible through native Forms process or would Workflow be involved?  I'm envisioning possibly two forms processes; one that collects the initial information and a second that is launched via Workflow from the first.  The second one could be triggered multiple times, but that creates multiple Forms processes for one invoice, when the goal is to have reconciliation back to the original invoice.

Please advise.

Thanks!

 

0 0
replied on May 23, 2023

Something to be mindful of is that it you can generate parallel user tasks, however, if you have multiple people working on the same table that can create problems because the individual tasks are not "synchronized" in that sense.

For example, if you have 3 users and a task for each, when user 1 updates the table with their information, that doesn't automatically update the values in the user 2 task. As a result, when user 2 submits their task, it will effectively overwrite whatever user 1 entered because its the same variable.

Some ways to prevent this include:

  • doing things sequentially so there's no chance of conflicting updates
  • cancel and recreate the parallel tasks after each update so the task has the latest data (you can do this using Signals)
  • use separate variables for each user so they don't conflict and combine the data
  • use an external database to track/hold the data for the course of the process
    • Use workflow after the initial submission to create a table for the data
    • Update the associated row each time a user submits their task; this way you can ensure only the target user's row is updated
    • Connect the table to a lookup rule so you can make it pull the latest data every time a user opens the task

Unfortunately, there's no "easy" solution and the specifics are really going to vary based on your specific use case, but it is possible.

1 0
replied on May 23, 2023

Thank you Jason, I didn't specify that the variables would have to be separate tables per user in the split for this scenario to work.  You can have all the individual tables show on the step to the AP and then calculate a final total there.

0 0
replied on May 23, 2023

I've done something similar to this where the form is kicked off by one person filling in certain information and selecting departments that need to include information as well.  The drop down pulls the user data from SQL (or you could assign teams) so it pulls the AD account to assign the form to.  Use a parallel to send the form to multiple people at once and use show hide rules and curstep JS to determine who needs to complete what pieces.  Close the parallel activity so that it waits for each person to complete their portion.  Once everyone is done, the form goes to the next step (back to your AP clerk).  You dont have to use workflow unless you want to capture the data in SQL for additional use later.  

2 0
replied on May 23, 2023 • Show version history

We have both a Purchase Requisition and an Invoice Distribution Form that route to multiple fiscal officers for info/approval before grouping all information together to send along to other steps in the process. This is all done through Forms (built in v10, and tested using v11 Classic Designer).

These processes were built by two different developers and handled in two very different ways.

One is done without Javascript. That developer collects the userID of the Fiscal Officer in a hidden field in the table (using a lookup tied to our AD), then pulls that value down into a hidden field outside of the table (using the field formula), so he can compare the fields and whittle down to only distinct userIDs (so each Fiscal Officer only receives one task, even if they are listed in more than one row). This works because he was able to get the process owners to commit to a maximum of six potential fiscal officers. He then uses an inclusive gateway in the process diagram to distribute the tasks. 

The other process is managed using Javascript and allows for an infinite number of Fiscal Officers. If you're interested in this method, I can ask that developer to hop on and provide the code. 

I hope that helps!

EDIT: I realize this may not be helpful to others in the future, so I've asked @Genny Maguire to provide her Javascript code and describe how she handles this dynamically. Thanks, Genny!

2 0
replied on May 23, 2023 • Show version history

I have three separate collections.

The first Collection is where who needs to sign for each BP number is selected by the initiator.

The second collection is hidden that whenever a new signatory is selected in the first it updates using JavaScript to only include those ids that are unique. In my original code I did this the hard way, but now what I would do is looping through the table and adding each value to an array then use a JavaScript set object to make sure they are unique.  

I have a loop in the process that keeps track of what person’s signature is needed next. This is based on the length of the second collection and the next signature needed index. In JavaScript when a new signature is collected then the “current index” goes up by 1.

The third collection is similar to the second in that it holds only unique people, but it’s where the signatures are collected for each in the second list. I did this because a new row is only added when the next signature is collected. This happens on the “Signature Required:“ task. When a new row is added the id is pulled from the second collection in the same row index. 

 

This is what the loop looks like in the process map. 

 

I did not include any code in part because as I said before I would do it a bit differently now, but if you want I can just let me know. 

 

EDIT: There is a hidden field that holds the next signatory AD Name. To start it is set to the first person to sign then is updated on the “Signature Required:“ task.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...