Setting up the full app
Once done with the previous section, you can delete the “First Run” knowledge model and validation view (or leave it in the package, as you prefer) and use the full knowledge model and Action View.
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.
Apart from the sensor results, the Action View also requires the knowledge model definitions (i.e. records, attributes and variables) to align with the data model. Again, all variables and definitions are based on the SAP ECC standard A/P connector. Any deviations need to be customized.
The full knowledge model
Let’s first examine and adjust the knowledge model “KM Duplicate Checking”:
Apart from records, attributes, KPIs and variables, the knowledge model also comes with useful, predefined filters which may be useful to apply (e.g. "FILTER_DUPLICATE_CHECKER_LEASE" filters out invoices that are lease payments). Out-of-the-box, the sensor uses the two filters "FITLER_DUPLICATE_CHECKER_INTERNAL_VENDOR" and "FITLER_DUPLICATE_CHECKER_SHORT_REF"
Similar to the steps performed in section "Your first Duplicate Checking run", make sure that at least the following variables and corresponding attributes are correctly defined, so that ML Sensor works:
Object
Standard SAP ECC definition
INVOICE_ITEMS_TABLE
BSEG
INVOICE_HEADER_TABLE
BKPF
VENDOR_MASTER_TABLE
LFA1
INVOICE_VALUE
WRBTR
INVOICE_REFERENCE
XBLNR
INVOICE_DATE
BLDAT
VENDOR_NAME
NAME1
ACTIVITES_TABLE
_CEL_AP_ACTIVITIES
VARIABLE_REVERSE_ACTIVITY
Reverse Invoice
VARIABLE_CREDIT_MEMO
Credit Memo
Invoice Record
${INVOICE_ITEMS_TABLE}."MANDT" ||
${INVOICE_ITEMS_TABLE}."BUKRS" ||
${INVOICE_ITEMS_TABLE}."BELNR" ||
${INVOICE_ITEMS_TABLE}."GJAHR" ||
${INVOICE_ITEMS_TABLE}."BUZEI"
Make sure that the INVOICE_REVERSAL_FLAG is defined correctly through the variables VARIABLE_REVERSE_ACTIVITY and VARIABLE_CREDIT_MEMO. Through this flag, the number of false positives can be further reduced
Any other definitions used in the View can be also adjusted and refined later
Configuring the sensor
Now that you are familiar with the knowledge model and have adjusted the minimum knowledge model definitions for the sensor, it is time to reconfigure the sensor with correct filters and also the reversal flag.
Go into the ML Sensor and switch the knowledge model to "KM Duplicate Checking".
Verify that "Invoice Record" is selected.
Select the vendor name "INVOICE_VENDOR_NAME", invoice value "INVOICE_VALUE", invoice reference "INVOICE_REFERENCE" and document date "INVOICE_DATE".
Apply the reversal flag "INVOICE_REVERSAL_FLAG".
Add the default filters “Reference Length longer than 4” and “Filter out internal vendors”.
Add any other relevant filters to reduce the number of documents checked.
Save and publish the package.
Custom matching logic
Apart from the default configuration using the ML Sensor, it is also possible to extend and customize the matching logic. This is done in the knowledge model by defining a custom object.
Configuration changes
During implementation and validation, you may want to change the configuration of the Duplicate Checking App. This will trigger background behavior to make sure that there are no conflicts with the prior setup. This section explains the different scenarios that can occur depending on the algorithm versions.
With the old algorithm, compatible with package version 1.X and lower, a clean up of the entire data pipeline is triggered whenever there is a published change in the ML Sensor itself (e.g. adding or removing a filter) or in the knowledge model definitions used in the ML Sensor. This includes the deletion of the Duplicate Checking App related (1) data jobs, (2) tables in the pool and (3) tables in the data model. To remove any loaded tables, a complete data model reload is initiated as well.
The new algorithm, compatible with package version 2.X, completely changes the behavior of how configuration changes are handled. For more information on Duplicate Checking App 2.X, see Release Notes January 2023.
Changing filters or the underlying PQL of filters used in the ML Sensor does not result in a reset of the data pipeline. Instead, already formed groups are flagged or unflagged automatically by setting the column “FILTERED_OUT” in the “DUPLICATE_INVOICES” table either to 1 (“yes”) or 0 (“no”). Only one document has to be filtered in the ML Sensor to flag an entire, already formed group. Flagged groups (with “FILTERED_OUT” = 1) are filtered in the front-end.
Changing the display name of attributes used in the ML Sensor results in the renaming of the respective column in the “DUPLICATE_INVOICES” table.
Changing the PQL definition of attributes used in the ML Sensor does not result in any changes to the data pipeline. The table “DUPLICATE_INVOICES” is simply appended.
Changing the PQL definition of the record identifier used in the ML Sensor results in a reset of the data pipeline and the archiving of the “DUPLICATE_INVOICES” table (see Components and data flow).
Activating augmented attributes
Once the sensor has run successfully and the results are available in the data model, the last step of the installation process is to enable the user feedback workflow by activating augmented attributes. These are special attributes stored directly in the data model to capture user feedback (more information here).
To enable augmented attributes, make sure that the “Knowledge Model Name” variable contains the correct knowledge model key (format: package-key.knowledge-key). By default, the variable should contain the correct value. However, any package key changes, either resulting from copying the package or downloading the app more than once, require you to adjust the variable accordingly. This is necessary as augmented attributes tables are generated once per data model but multiple packages with different knowledge models can write back to the same augmentation table.
Go to the package and click on of the knowledge model, then on “Key”.
Copy the knowledge model key (including the package key) to your clipboard. Update the “Knowledge Model Name” variable and save the knowledge model. Then publish the package.
 |