Skip to main content

Celonis Product Documentation

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.

  1. Go into the ML Sensor and switch the knowledge model to "KM Duplicate Checking".

  2. Verify that "Invoice Record" is selected.

  3. Select the vendor name "INVOICE_VENDOR_NAME", invoice value "INVOICE_VALUE", invoice reference "INVOICE_REFERENCE" and document date "INVOICE_DATE".

  4. Apply the reversal flag "INVOICE_REVERSAL_FLAG".

  5. Add the default filters “Reference Length longer than 4” and “Filter out internal vendors”.

  6. Add any other relevant filters to reduce the number of documents checked.

  7. 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”.

knowledgemodelkeychange.png

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.

knowledgemodelname.png