RPA for Accounts Receivable Processes

Synopsis of the bot process

Video Transcript

I will be demoing our AR notifications process. This demo will cover the steps performed by the robot, examples of orchestrator queues and engineering business rules involved in this type of process.

Here’s a brief overview of what takes place during this process:

• The robot reads data from input files,
• uploads an image to the queue,
• pulls the same data from the queue,
• and processes it for each client.

Here you see two of our input files. They are invoice support and the AR email report. Let’s focus on the invoice report first and then go from there.

The report reads the data listed on the report line by line. It focuses on the Age column primarily. If an item has a positive age, then the client project will be flagged for processing. So if you see any item with a Age over zero, then it’s flagged for processing. Vice versa, if the invoice item has a negative age, it is then skipped by the robot.

The robot does this line by line and determines which items will be uploaded to the queue. Each item added to the queue is grouped by client and then the project name. One client can have multiple projects within the queue that can contain multiple invoice items.

For example, Company One can have multiple invoice items within Project One, and then so forth with Project Two, Three and Four. Next up, let’s focus on the AR email report. Same thing as the previous report, the robot reads the data listed on the report line by line as well.

Just to clarify, the information gathered here is done at the beginning of the process along with the invoice report, but for this one it’s stored. It is later used when the robot begins to process the queue items.

Within this report, the robot focuses on three columns, the Name column, the Email column, and the CC column. The robot uses the Name column to match the client and project names from the invoice report to find the correct match on the email report.

Now within the code, let’s run the process and see it in action. I put a couple of breakpoints within the code to stop it at essential parts. So the first part is going to stop right before the items are added to the queue.

Now you can see that the process has been stopped right before items have been added to the queue. Once I hit continue, we will then see items being added to the queue. So let me go ahead and do that.

Look in this panel here. See that these three items were found within the invoice report and then uploaded to the queue. This is the queue name that it was added to. Let’s take a brief pause and transfer over to our Orchestrator. And let’s view those items within the queue as well.

Three items were uploaded to the queue. We have Project One, Project Two, and another Project One. This essentially means a project of the same name was uploaded for a different company.

Let’s continue along with the process and we’re going to see the first item being processed.

The robot is going to to begin processing the first item. I put another breakpoint in the email section and we’re gonna stop before any emails are sent off just to give you a little explanation of what’s going on.

It noticed that there were two rows that were within the queue for that current item. That means in that project there were two invoice items related to it. From there, it read the HTML email script which is the template file that was sent out to clients. From there it initialized all the variables based on the client, that it is sending to. And then it replaced all those values.

That is what has taken place at this point. The next step would be for the robot to actually check that stored email list that we talked about earlier, which is the email input file. The robot is going to be checking those three columns: Name, Email and CC columns.

Let’s go to the next step.

The robot found the match! The robot sent an email for that item, meaning the robot sent an email item out to the client for that item, and then ended that transaction.

Now it’s going to begin again with the next item in the queue. This is going continue on until it reaches the last item.

When it’s finished, we’re going to check the in-process notifications for the clients, for our internal team, and our queue.

Now we’re at the point where we see our internal email.

We have an Error Email workflow and Success Email workflow. For this demo, we’re going to do our “Happy Path” which is our success workflow. We’ll hit ‘Continue’ and the email has been sent off.

Let’s go check our queue and see all the items that were processed.

Now in our queue, you can see that each of our items were processed successfully. Let’s look at the monitoring report in a dashboard type view.

Here’s a dashboard for our demo AR notifications queue. You can see that we processed three items. They were all successful. We have our Queue Dynamics, Unprocessed Items (which we have none for this example), we didn’t have any errors and we’re not using any SLAs.

Now let’s take a look at our notifications.

Here you see two examples of our client emails. This is Company One with a past due invoice for Project Two. Here we have 15 days past due for this invoice. On the other project, we have three days past due. When we open up one more, it’s for a different company, and it has a credit memo listed, so we have a credit balance, or negative balance. You can see here how it handles negative items.

Let’s transfer over to our internal company email once the project is finished. Here you can see each of the items processed by the robot during run time. This gives the reviewer a quick guide to see each of the items there were processed along with the actual report. The attached report is a detailed step by step guide on what the robot actually did during the process, in case there were any errors.

There’s more to explore at Smartbridge.com!

Sign up to be notified when we publish articles, news, videos and more!

By signing up for emails from Smartbridge.com, you agree to our terms and privacy policy.

Other ways to
follow us: