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 move on to using 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.
Steps:
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
Important
Any changes made to the sensor or knowledge model definitions used in the sensor, trigger a clean up of the entire data pipeline. 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 triggered as well.
Configuration changes
During implementation and validation you may want to change the configuration of the Duplicate Invoice Checker App. This will trigger behaviour in the background to make sure that there are no conflicts with the prior set up. This sections explains what happens once you do that.
First, remember that the ML Sensor orchestrates the app. It reads PQL configurations from the Knowledgemodel (Records, Attributes and Filters) and uses these to query data. Then it calculates the Duplicates and writes back results into tables in the Data Pool and Data Model (Group Duplicate Invoices, Duplicate Invoices). If you want to recap this in more depth please check out the installation guide again. Whenever you make changes to any components in the Knowledge Model that the ML Sensor uses, the application resets.
Why? Let’s say you add a new filter. Then we want to make sure we recalculate all Duplicates under that new configuration. So in the background, the ML Sensor will delete the old “GROUPS_DUPLICATE_INVOICES” and "DUPLICATE_INVOICES” tables in both the data pool and the data model and run a fresh full load.
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.
 |