Solution Design Document

Invoice Entry Project

Revision History
Rev. # Date Section/Page# Revision Summary Author
1 26/11/2024 All Created first version Meenakshi Bhatia

Contents
I. PURPOSE...................................................................................................................................... 3
II. AUTOMATED PROCESS DETAILS.................................................................................................... 3
Summary................................................................................................................................................3
III.RUNTIME GUIDE............................................................................................................................... 4
1. Architectural structure of the Master Project.................................................................4
2. Master Project Runtime Details....................................................................................... 5
3. VendorDispatcher.............................................................................................................6
4. VendorPerformer............................................................................................................. 6
5. Project(s) workflows.........................................................................................................7
6. Packages............................................................................................................................7
7. Assets................................................................................................................................. 7
8. Exceptions.........................................................................................................................7
9. REPORTING........................................................................................................................8
10. Security......................................................................................................................... 9
11. Compliance Considerations........................................................................................9
IV. OTHER DETAILS...................................................................................................................... 10
V. GLOSSARY.......................................................................................................................................10
I. PURPOSE
Outlines the major components of the Master Project (the overall output of the
development, containing one or multiple projects that together cover the scope of the
robotic process automation) taking into account all the business restrictions (scheduling,
peaks, future increases in volume etc.). The focus of the Solution Architect will be on:
 Robustness
 Scalability
 Efficiency
 Repeatability
 Re-usability of component
The information herein is targeted primarily at the developers that will initially implement
the solution and subsequently at the support developers in case of change requests.
The automation solution will utilize the RE framework with separate Dispatcher and Performer
model. The Dispatcher will be responsible for collecting all key data necessary to generate a
VendorOnboarding transaction item which will be committed to the appropriate Work Queue
within the UiPath Orchestrator. In turn, the Performer will work each transaction sequentially,
focusing on the work steps required to enter vendor details or notify the vendor that they are
already entered in the system.

II. AUTOMATED PROCESS DETAILS

Details filled in need to reflect the actual information for the Master Project released for
production. The following table will be populated:

Item Description
Master Project Name Invoice Entry Project
Robot Type Unattended
Orchestrator used? Yes
Scalable Yes
UiPath version used 2024.10

Summary
The process saves attachments from unread emails, extracts the information within and inputs the data
into 2 external applications – an ERP (System1) and a CRM (System3).
The project Invoice Entry Process Automation using RPA (Robotic Process Automation)
streamlines the manual process of handling invoices, ensuring accuracy, efficiency, and time savings.
This technology employs bots to extract key data from invoices, validate the information against
predefined business rules, and input it into enterprise systems such as ERPs.
The RPA solution integrates optical character recognition (OCR) to digitize invoice data from various
formats, such as PDFs, emails, or scanned documents. It then cross-verifies details like vendor names,
invoice amounts, and dates with existing records. Exceptions or discrepancies are flagged for human
intervention, ensuring compliance and reducing errors.
This automation reduces manual workloads, minimizes errors, accelerates processing times, and
improves operational efficiency. It also enhances scalability by managing high volumes of invoices
without additional resources. Ultimately, the RPA-driven process ensures a seamless and reliable
approach to invoice management, benefiting both the organization and its stakeholders.
III. RUNTIME GUIDE
1. Architectural structure of the Master Project
Display the interaction between components (package / robots, Orchestrator queues, and
running order) in a diagram.
 2. Master Project Runtime Details
Outlines the details of the automated process by filling in the table below.
ITEM NAME DESCRIPTION
Fill in each bolded section - empty fields are not
allowed. If the section does not apply to your
automation then mark as
n/a.
Production environment details local machine
Prerequisites to run Web browser (Chrome), Excel

Input Data Unread emails containing invoice attachments

Expected output Email notifications to vendors confirming invoice receipt

How to start the automated Triggered by a scheduled time

process
Reporting
(queues reporting, Kibana or
another platform)
How is Orchestrator used?
Password policies n/a
(mention any specific compliance
requests)
Stored credentials Credentials stored in Orchestrator Assets, linked to the
(Never use hardcoded credentials current folder.
in the workflow!)

List of queues names

(Naming convention:
ProcessName_QueueName)
Schedule Details daily
Multiple Resolutions Supported? n/a
(in case of image automation /
Citrix and VDI)
Recommended Resolution n/a

3. Project(s) workflows
TO BE ADDED AFTER DEVELOPMENT

Workflow Name Description

Main.xaml The entry point workflow that orchestrates the
execution of all other workflows.
 4. Packages
Include the list of packages and high-level description for each of them, to explain their purpose
Package Name Description
UiPath.Excel.Activities
UiPath.System.Activities
UiPath.Testing.Activities
UiPath.UIAutomation.Activities
UiPath.PDF.Activities

5. Assets
TO BE ADDED AFTER DEVELOPMENT
Package Name Description
NA

6. Exceptions
During the process run, certain scenarios might arise that the robot cannot process and will
require manual intervention. These are defined as exceptions. Below are the two types of
exceptions:

Business Exceptions – A business logic error or missing data which is encountered on a daily basis
by the business unit. There is a clear workaround that can be resolved by reviewing the case.

Application Exceptions – This is defined as an unexpected error encountered by the robot such as
a network error or an application error which is outside the control of the business unit and will
need to be resolved by IT or the RPA team.

10. Testing
Testing is an essential part of any development process. Its main purpose is to ensure the
automated process is functioning in the way it is supposed to. By beginning the testing process
during development, any issues, bugs, and errors can be identified and potentially corrected at
the earliest possible opportunity.

Each level of testing is responsible for different parts of the automated solution, reassuring high
quality of each of the elements delivered. Each of the stages must be completed before the
solution is released to the production environment.

The stages of testing are:

Unit Testing - Focuses on the individual components and workflows created specifically for the
process in scope, assessing whether they function as according to the original design.

Responsibility: Development Team

System Integration Testing – Ensuring all required functionalities, both business and technical,
are implemented, as well as ensure unit testing has been completed successfully, development
Best Practices have been applied and code review has been completed by a Solution Architect.
There will usually be a round of fixes to be implemented before the automation can proceed
further.
Responsibility: Dedicated tester / Solution Architect

User Acceptance Testing – Process team take responsibility of this phase of testing to ensure
they are happy with the results of the automated business process. Sign-off of this phase is
business led and mandatory in order to proceed further. Generally, there will be iterative fixes to
be implemented that have been discovered during the user testing of the automation.

Responsibility: Dedicated tester C Business Unit

Pre-Production Testing – Validates the readiness of the product prior to Production deployment.
Responsibility: Dedicated tester, Development Team C Solution Architect

Dry-Run –Monitor the initial cases run by the process to account for any environmental
differences between Pre-Production and Production.

Responsibility: RPA Business Analyst C Business Unit

11. Security
Security is a vital aspect of digital processes as it provides an extra layer of protection from the
public. There are different ways in which security is implemented when automating an existing
process, some of which are discussed in this section.

Sensitive data such as passwords and client/customer information (like information stored in
databases) must never be unnecessarily stored outside of its origin application when handled by
the RPA solution.

Similarly, user and application credentials used by the RPA solution must also never be
unnecessarily stored or shared with any unauthorized persons. In addition to that, if the robot is
dealing with password reset policies that are internal to the client, those policies must be
followed to ensure security is maintained.

API keys are often used within RPA solutions to allow access to certain applications, and these
are ideally stored in Orchestrator credential assets and only accessed when needed. As with
credentials, they should never be shared or stored elsewhere.

12. Compliance Considerations

Display the interaction between components (package / robots, Orchestrator queues,
and running order) in a diagram.
Item Specific Considerations (use N/A if not applicable)
Sarbanes Oxley (SOX) n/a
HIPAA

FERC Standards of Conduct n/a

Personally Identifiable Information
(ensure process follows PoLP)

Others
IV. OTHER DETAILS
Future Improvements
Fill in any improvements that need to be considered for the future: NA

Other Remarks
Please mention here any other points that you consider relevant for the automation process: NA

V. GLOSSARY
The key terms used in the Solution Architecture Document for the Invoice Entry Process in RPA
Technology are defined below:
Master Project
The overarching development output encompassing one or more projects that together automate
the entire scope of the invoice entry process. There is a one-to-one relationship between the
Master Project and the Process to be automated, as outlined in the Process Design Document
(PDD).
Project
A UiPath Studio project consisting of one or more workflow files. Each project addresses a specific
component or scope within the invoice entry process. Projects can either be converted into
individual packages or combined into a single package based on the requirements and limitations
of the automation. Projects are primarily defined during the development and support phases of
automation.
Package
The compiled output of one or more projects, deployable on a robot machine. A package is
executed by the robot service and is the unit of execution during the running phase of automation.
Only one package can be executed at a time by a robot.
Workflow
A modular component of a package that encapsulates a portion of the invoice entry logic.
Workflows are saved as .xaml files within the project folder and can be invoked from other
workflows. The initial workflow file serves as the entry point for package execution. Workflow types
include:
Sequence: Activities are executed sequentially, step-by-step.
Flowchart: Activities are visually connected, offering a clear view of the workflow’s logic.
Flowcharts can be exported as images for documentation.
State Machine: An advanced structure for organizing workflows, allowing transitions between
defined states.
Activity
An individual action performed by the robot, such as extracting invoice data, validating inputs, or
entering information into an ERP system.