The anatomy of two-way match for SAP Solution Accelerators part two

Introduction

As promised, today, we are continuing our two-part series on the anatomy of a two-way match for SAP. In this second part, we’ll dive into the technical aspects of extracting data from invoices and storing the data from a high-level perspective. Performing a process order (PO) matching at a deeper technical level is another thing we are going to explore. Now let’s get into it.

Data extraction

Each invoice found within a document will be processed (a single document can contain multiple invoices) and if needed, the data can be validated manually using an interface like the one below:

Store extracted data in UiPath Data Service

All extracted data will then be passed to UiPath Data Service to be used in the next steps of the process. The UiPath Document Understanding process will then create a record for each new invoice in the AP Invoice Data Service Entity. These are the starting fields of the entity, but they can be changed based on your use case.

Each invoice will have a set of line items associated with it (in fact, the Document Understanding process is configured by default to consider the line items as mandatory, and no invoice can be processed further without them).

Invoice Line Items will be stored in the AP Invoice Line Item entity and each AP Invoice Line Item record will be linked to an AP Invoice record. These are the starting fields of the entity, but they can be changed based on your use case:

Once the invoice information has been successfully added to Data Service, custom processing logic should be used to determine if PO Matching should be applied, or if the process should jump straight to the Performer.

PO matching process

The PO Matching process provides that an Invoice is matched to a Purchase Order.

By default, the following logic is applied with an option for further configuration:

• If the Invoice contains a PO Number, the process will try to identify it in the F&A application

• If there is no PO Number, the process tries to find some potential matches based on the Supplier Name (this should be changed based on your use case).

• If no potential PO Matches are found, the process will throw an exception.

• Logic if PO Matching should be done automatically or manually, through an Action Center Task.

• Once the PO Matching step is completed, the matched PO ID and PO Line Item IDs are added to the Data Service Records.

• Invoice is passed to the Performer process.

Manual two-way matching between Invoice and Purchase Order

This section describes the out-of-the-box behavior of the manual 2-way matching process. If the PO matching will happen manually, an Action Center task will be created. It is in the UiPath Action Center, and it will contain:

A set of Related Purchase Orders. The user can select the PO using a dropdown.

Once a PO is selected, all PO-specific information will be displayed in the Action Center Form, along with the PO Line Level Information:

In the PO Line Items table, each field can be matched to an invoice line item:

Instead of choosing one of the predetermined Purchase Orders, the user can also submit a custom Purchase Order number:

PO matching template

The PO matching process provides that the invoice is matched to a purchase order. The matching steps also include logic that matches the Invoice Line items to the PO lines.

The main steps of this process are already detailed in section PO Matching Process.

This process is a long-running one, and each job will process a single Invoice at a time. The default manual matching should not need major changes in most cases, but the automatic matching flow contains several workflows that are intentionally not configured, as their logic is highly specific and cannot be reliably incorporated into a framework.

In the next section, we will look at the configuration files that are part of the PO Matching Template and go through their scope.

Main.xaml - This is the execution entrypoint of the process. This workflow contains a flowchart where the PO Matching Steps are detailed. InitProcess.xaml - All process initializations will take place in this workflow.

InitiAllSettings.xaml - Initialize, populate, and output a configuration Dictionary to be used throughout the project. Settings and constants are read from the local configuration file, and assets are fetched from UiPath Orchestrator.

InitAllApplications.xaml - Opens applications used in the process and performs necessary initialization procedures (e.g., login).

GetTransactionData.xaml - Gets a transaction item from the PO Matching queue. Our item will represent an AP Invoice that will undergo a PO Matching Process.

If there are no transaction items remaining, out_TransactionItem is set to Nothing, which leads the process to the End state.

EndTransaction.xaml - This workflow will contain any post-PO Matching steps.

The following steps will be executed for a successful transaction:

• Update the AP Invoice Record PO Number and Status fields

• Update the LinePONumber field in the AP Invoice Line Item Records

• Add a queue item for the current Invoice to the Performer queue

Default does not add the logic for handling unsuccessful PO Matching transactions and should be implemented according to your specific use case.

SetTransactionStatus.xaml – This workflow sets and logs the transactions status along with extra log fields. There can be three statuses: Success, Business Exception, and System Exception.

Depending on the queue Item Status set here, the Status field of the AP Invoice Record is also updated.

Only System Exceptions obtained on the last Retry of a transaction Item will cause the System Exception status to propagate in Data Service.

SendExceptionEmail.xaml - This workflow sends an email containing the details of an exception. AbortProcess.xaml - workflow executes when the process is aborted due to an exception. Any error cleanup should be done here.

Purchase order matching

Now that we’ve talked about the Matching Template, let’s see how the actual logic around PO Matching is performed.

GetRelatedPOData.xaml - Finds the Related POs Based on the Current Invoice.

The following logic is used:

• If the Invoice contains a PO Number (ExtractedPONumber field in the AP Invoice record), the process will try to get it from SAP. This uses the SAP API service APIPURCHASEORDERPROCESSSRV and configurable query filter POMatchingPOGetDetailsQuery

• If there is no PO Number, the process tries to find some potential matches based on the Supplier Name (this should be changed based on your needs): Finding the Supplier ID is done using the configurable query in the POMatching_POGetDetailsUsingSupplierIDQuery asset. Finding the related PO uses the query in the POGetDetailsQuery asset.

After these steps, if no potential PO Matches are found, the process will throw an exception.

By default, this component uses the SAP Reusables library named SAPReusablesAPI, but this and the logic for finding Related POs should be customized according to your specific process. This logic should serve as an example and shouldn’t be used as is!

Our POs are obtained/converted as a JObject, but then converted back to a string to avoid any serialization issues when the workflow is suspended. Change this, if necessary, depending on your process' needs.

ChooseProcessingApproach.xaml - Logic used to decide if the PO Matching Action Center Task should be created. This component is currently intentionally empty and should be implemented according to specific use case.

AutomaticPOMatching.xaml - This workflow will perform an automatic matching between a PO and an Invoice.

This component is currently intentionally not configured and will throw an exception if executed. This step consists of highly specific logic and should be implemented according to your use case.

ParseInvoiceLineItems.xaml - Extract the Line Item Details from the queue Item and save it as a data table that can be used in the PO Matching Form. This workflow should be used in case we’re opting for a manual PO attaching.

PrepareApprovalData.xaml - This workflow will prepare the PO and Invoice data that will be displayed in the Action Center Form. For each PO, we will create a DataTable containing its properties (each property will consist of a separate row) and a second DataTable for its line-item data. These DataTables will be then stored in 2 separate Dictionaries<String, DataTable> where the Key will be the PO Number. These two dictionaries will be used later to populate the PO Matching Form with data.

CreatePOMatchingForm.xaml - Creates the PO Matching Task in Action Center where the user can manually select the PO to match to the current Invoice, along with also matching the Line Item Data.

ExtractTaskData.xaml - workflow that parses the PO Matching Data submitted by a user via the Action Center task. Parameter outSubmittedSuccessfully will be False if the user clicked the Cancel button and True if the user clicked the Submit button. If the user submitted a PO number that is not part of our initial list, we will save it in the parameter outCustomPONumber. If user matched any Invoice line items to PO line items, we will update the Invoice Line Items list to reflect that.

InvoiceMatchingWithUserProvidedPO.xaml - This workflow solves the matching between the custom PO given manually by the user and an Invoice. This component is currently intentionally not configured and will throw an exception if executed. This step consists of highly specific logic and should be implemented according to specific use cases.

Now that is all information for today. Do stay tuned for our last and final part of the series. Meantime explore Solution Accelerators library.

Don’t forget to catch up with all the UiPath DevCon 2024 session recordings. Register now to get access to the videos.