Your first Duplicate Checking run
After verifying that all prerequisites have been ticked off, it’s now time to set up the first, basic Duplicate Checking run. This video provides a walkthrough of the step-by-step guide below.
Important
Please note that this is a trial run. The goal of this section is to take a step back and walk through all steps of the data flow to make sure you understand the setup of the app and know how to troubleshoot going forward. You can skip this section and process with "Setting up the full app" if you are confident.
Download the app from Marketplace:
Note
The components in the "Action View" are initially broken and will only be populated if the results of the ML Sensor are available in the data model.
Assign a data model to the data model variable in the package settings.
Create a new knowledge model and name it “First Run”.
Some records and KPIs are already defined. These are auto generated and can hidden by clicking on the blue button.
The knowledge model should now be empty. For the sensor to work, an invoice record with the attributes invoice value, vendor name, invoice reference and document date needs to be created. Although you could create the record and the attributes directly, we first create variables, which are then used with the record and attribute definition. This is best practice and helps to reduce effort. The standard knowledge model also uses variables most of the time. Remember that we expect the data model of a standard SAP ECC A/P connector. If you have a different source system, you need to map the tables to these knowledge model objects.
Create the following variables:
Add the record for the invoice line item table. The identifier of the record should be the primary key of the BSEG table, concatenating MANDT, BUKRS, GJAHR, BUZEI and BELNR:
${invoice_line_item_table}."MANDT" ||${invoice_line_item_table}."BUKRS" ||${invoice_line_item_table}."BELNR" || ${invoice_line_item_table}."GJAHR" ||${invoice_line_item_table}."BUZEI"
Create the invoice attributes:
Create a dummy filter for the ML Sensor
“FILTER ${invoice_line_item_table}.${invoice_value} IS NOT NULL;”There should be one record, four attributes, one filter and seven variables if you do not count the tables and auto generated KPIs
Sensor overview:
In general, the Duplicate Checking ML Sensor (name: “Sense Duplicate Invoices”) is the starting point of the app. The sensor takes the definitions from the knowledge model defined earlier. Currently, four in-build comparison fields can be used:
Vendor name (default: LFA1.NAME1)
Invoice Value (default: BSEG.WRBTR)
Reference Number (default: BKPF.XBLNR)
Document Date (default: BKPF.BUDAT)
The “Reversal Flag” is used to identify invoices which were already reversed (i.e. they are invalid). The reversed status is applied to the whole group if all of the invoices in the group are caught by the statement in the reversal flag. By default, the configuration of this flag in the main knowledge model (key: "km-duplicate-checking") is based on the "Reverse Invoice" and "Create Credit Memo" activities. The "Reversal Flag" is optional.
Lastly, you can apply filters to the invoice scope to reduce the number of documents checked. At least one filter is required to run the sensor.
 |
Configuration steps:
Select the newly created knowledge model “First Run”.
Select the Invoice Record and the four complementary attributes ("Vendor Name", "Invoice Value", "Reference Number", "Invoice Document Date").
Select “none” for the “Reversal Flag”.
Remove any default filters in the filter section by clicking on the trash bin icon.
In the filters section, click on "Add Filter" and apply the dummy filter "DUMMY_FILTER".
Save the changes and publish the package.
Note
The sensor is triggered either by a data model load or by publishing of the package once changes to the knowledge model or skill have been made. The returned signals displayed in the sensor logs represent the newly found duplicate groups by the algorithm.
The sensor logs show the progress of the current Duplicate Checking run.
Tip
The running executions can be also seen by navigating to "Data", "Machine Learning", "Triggered", "Job" under "duplicate-checking". A running execution can be canceled by clicking on the three dots and selecting "Cancel".
Once successful, move to the next section. In case of an error message, check the troubleshooting guide. Make sure you followed all steps correctly.
The steps described above depict the standard setup and the default logic, where the algorithm is fully powered by the Machine Learning Sensor. It is also possible to customize the algorithm logic by defining custom matching patterns. These customizations are done in the knowledge model and will extend the configuration in the ML Sensor.
Validation view
To preview the results generated by the algorithm, you need a view. Instead of using the already existing “Action View”, let’s create a very simple validation view from scratch. This view helps you to understand the output of the algorithm and to troubleshoot any problems.
Create a new view in the same package with the name “Validation View” and link it to “First Steps” knowledge model.
Insert a KPI list using the Visual Editor and add the auto-generated KPI “Count Table Groups Duplicate Invoices” to the list.
Insert a second row in the layout using the Visual Editor. Create a table component in this second section and add the auto-generated attributes “Group Id”, “Group Status” and “Invoice ID” of the “Duplicate Invoices” record.
Save and publish the package. Congratulations, now you can review the first results of the ML Sensor.
