Views
The app architecture is focused on maintainability and reusability but having also customizations in mind. This is achieved by leveraging the Base and Extension functionality within the app, as well as through the use of embedded views.
Architecture
Action View
The architecture diagram below shows what views exist and how those component specific views are embedded in the Parked & Blocked Action View. The gray boxes indicate the different tabs of the Action View. The blue “Component Base Views” are separately defined Base Views that are embedded in the Action View at multiple places.
The yellow components are directly defined in the Action View.
 |
Component Base Views
The app comes with four central components: the KPI list, a KPI List for Parked & Blocked invoices only, a Breakdown Table and an Action Table that are used in multiple tabs as depicted in the diagram above. The standard configuration is located in the folder Bases/Components.
 |
This means in case you want to adjust the tables in the invoice table in the Parked & Blocked View, the update needs to be done in the “Action Table” view.
Profile Views
The App comes with two layers of profile views - the Action View is connected with the Invoice Details Profile View using the “KnowledgeObjectID“ INVOICE_CASE and showing contextual information of the invoice. From this View, linked Purchase Orders and Purchase Order Items can be opened using the “KnowledgeObjectID“ PURCHASE_ORDER and PURCHASE_ORDER_ITEM. Within the Profile Views, the app leverages again the concept of embedded views.
 |
Invoice Details
This approach is also used for the invoice details view. By default, the app comes with three different “issue views”: one for price-quantity variance, one for a vendor block and a default one in case the underlying issue is unclear. Depending on the recognized problem, only one of those views is shown in the Overview tab. Section Adding an issue details view describes how additional views for customer specific problems can be added (e.g. non-PO invoices, invoices in a workflow). While the components illustrated by the blue boxes are embedded in the invoice details view, the components illustrated in yellow are directly defined in the invoice details view.
 |
From the Invoice Details Profile View, the App allows access to Purchase Orders connected with the invoices by clicking on either the purchase order number or the purchase order item number.
Purchase Order Details
 |
The layout and all components for both views are defined in the view called “Purchase Order & Goods Receipt”. The views “Purchase Order” and “Purchase Order Item” embed the “Purchase Order & Goods Receipt” view and have a dynamic filter on top of it using the record variable. This setup allows you to use the same underlying view but dynamically filter on either the PO (EBELN) or on the PO ITEM (EBELN & EBELP), depending on the user’s click.
Content
The Parked and Blocked Action View consists of three central tabs:
Action View - Provides an actionable and intelligently prioritized list of parked & blocked invoices that need to be processed
Analytics - Consolidates the parked & blocked invoices and provides an aggregated view of the open issues offering various filter and breakdown capabilities.
All Open Invoices - Shows all non-cleared invoices including the ones not being parked & blocked to get insights into the invoice aging. It can be used to identify invoices that are not paid despite having no block or also for identifying open credit memos that should be raised.
The Action View tab has three main sections:
The KPI area showing key KPIs consolidating the table below.
The invoice table listing all relevant parked and blocked invoices in a prioritized manner (see Invoice Prioritization) and providing contextual information.
The sidebar enables the user to quickly filter on or search for the most relevant invoices.
The key element of the Action View is the invoice table showing all open parked and blocked invoices, already prioritized and sorted with regards to the objectives to realize On-Time Payment and Cash Discount.
Note
All relevant fields and KPIs have a detailed description providing some context around the calculation.
By default, the table comes with three app-specific interaction capabilities:
You can select the checkbox of one row and execute one of the available actions for an invoice (see Actions - Manual Sensor)
You can hover over the Status field, select the pencil, and then update the status directly in the table (see Celonis Invoice Status)
You can click on the blue invoice number to get additional invoice information in the so-called invoice details view.
By clicking on the blue invoice number, the invoice details for the selected invoice display in a side-panel. This view is intended to provide deep dive information to have a holistic understanding about the underlying issue, other invoices from this vendor, related documents (PO, GRs) what actions have been taken, etc.
While the tabs are the same for all invoices, the contents of the “Overview” tab varies based on the issue type. The goal is to always show the user the most relevant information based on the underlying problem. By default, the app distinguishes between the following issues:
Payment Block or Parked - The Overview tab shows details about the price and quantity match.
Vendor block - The Overview tab provides more context about the vendor’s master data, the vendor balance and shows all open invoices for this vendor.
No issue - The Overview tab shows the activity history.
In case the DM contains additional data (e.g. workflows, approval data), Adding an issue details view shows how additional detail views can be added to create for instance a specific view for a certain payment block key.
Note
The “INVOICE_CASE.PROCESSING_STATUS” field must not be removed from the invoice table as it is used to show the correct view for each problem (see Adding an issue details view).
Besides the Overview tab, the invoice details view comes with the following additional tabs:
Matching - Provides details about the price & quantity match between invoice and purchase order. If the underlying issue is a payment block, this tab is equivalent to the Overview tab. For non-PO invoices, the tables will be empty. By clicking on the blue purchase order number, a separate side panel for purchase order details will be opened.
Item Details - Contains details about the MM document in case a purchase order is available. For posted invoices, the view also shows details about the accounting document (FI).
Vendor Details - Provides details about the vendor master data and shows all open invoices from this vendor. In case the underlying issue is a vendor block, this tab is equivalent to the Overview tab.
Activity History - The event log for the selected invoice including all relevant activities in the ERP and in Celonis.
Notes - Make comments on the invoice and read your or other stakeholders comments.
 |
From the Three-Way Match tables, there’s an option to jump to the purchase order details to get a detailed understanding of the related order and its history. To correctly calculate the GR balance for the PO and which PO value has been already cleared by previous invoices, it’s important to consider the complete PO history including all invoices and credit memos. The KPI “# Rel. Docs” in the screenshot above indicates that for this PO, there are in total 447 related documents.
As we have only open invoices in the case table, the table EKBE with VGABE = 1 for Goods Receipt and VGABE = P,2,3 for Invoice Receipt is used.
Thereby, the View is coming with the following tabs:
Purchase Order - The waterfall charts consolidate all items and show in the purchase order header level which quantity or amount has been ordered, received, cleared and is still open. In the tabs and tables below, the matching can be analyzed from an purchase order item point of view (difference to matching on invoice details view, which is besides the GR Balance from the perspective of the invoice).
Goods Receipt Details - Shows a complete list of all individual GRs for the purchase order.
All Invoices for this Purchase Order - Shows all open and cleared invoices for this purchase order.
Settings View
The Settings view provides configuration options for all runtime variables. Once an app is published, adjustments of a runtime variable in the Studio doesn’t impact the published version on “Apps”.
In order to allow the update of the currency after the first publishing, the Settings View can be used.
Note
Updates on this Settings page on runtime variables are not user-specific but will be applied to all users.
 |
Validation and Error Resolution
View Validation
For the validation it’s recommended to start with the “Action View” and click through the app (KM and profile views need to be published first). As described in the previous sections, this is the central view the users will work on. All other views are just building blocks that are integrated into this view.
However, when noticing any error in the view, the “component views” need to be opened as most components are of the type “embedded view”.
Error Resolution
Having identified the erroneous component or content, toggle the edit mode and then click Edit Component to open the visual editor. There, you will be able to update/remove content or identify the underlying KM ID to perform a potential update there. For certain changes it is required to open the code editor of the complete view (e.g. disable drop-downs).
To do this, you can perform the following steps:
Identify the component or content affected by toggling in Edit mode while hovering over the component affected.
Select Edit to open the code editor, view the component definition and copy the component ID.
Open the YAML editor for the entire view.
Paste the component ID.
Select Preview Final View and copy and paste the entire component configuration into the YAML editor.
Verify that the YAML is correct and update as necessary. It is recommended to only keep the updated config in the YAML as everything stored in the extension is overwriting the definitions in the BASE making it potentially harder to install updates.
In order to disable a field, you can use the scopes attribute (e.g. scope: DISABLED or scope: HIDDEN).
Save the YAML.