Questions and Answers

Why can batches not be loaded in Input Management?

In short

When opening the Input Management Dashboard, an error message appears and the affected batches cannot be opened. The cause is inconsistent content entries in the database, created by a race condition during document creation. The faulty entries must be cleaned up manually in the database.

Situation description

When opening the Input Management Dashboard, an error message appears and the affected batches cannot be opened.

Cause

The problem is caused by a race condition during the creation of documents in the database.

As a result, multiple active content entries are created for the same document_id. The dashboard cannot correctly process these inconsistent data entries.

Prerequisites for troubleshooting

The following access rights and tools are required: - Access to the PROD-DE cluster - Permission for port forwarding - Access to the stp_im database - An SQL client, e.g. pgAdmin 4

Solution

1. Establish the connection to the database

To access the database, a port forwarding connection must first be established:

kubectl -n lexolution port-forward svc/portforward-aurora-shared 5432:5432

This enables local access to the database.

2. Identify affected documents

Execute the following query on the stp_im database:

select document_id, count(*) as anz
from content
where deleted_at is null
  and content_parent_id is null
group by document_id
order by anz desc
limit 10

The top entry with the highest count (anz) usually identifies the affected document_id.

Note
In rare cases, multiple documents with anz > 1 may exist. The following steps must then be performed for each affected document.

3. Identify the faulty content entry

Insert the identified document_id into the following query:

select *
from content
where document_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
  and deleted_at is null
  and content_parent_id is null
order by created_at desc

Two active entries should be returned. For the cleanup, the id of one of the two entries is required — it does not matter which of the two entries is used.

4. Clean up the faulty entry

Execute the following query:

update content
set deleted_at = CURRENT_TIMESTAMP,
    deleted_by = '11111111-1111-1111-1111-111111111111'
where id = 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'

Note
The WHERE clause must never be removed. Without this restriction, all content entries would be marked as deleted.

5. Verify the result

After the cleanup has been completed successfully, the Input Management Dashboard should open correctly again. The affected batches can then be loaded again.

In short

To export all documents from the Recycle Bin, the Input Management CLI has been extended with an administrative function. After authentication, the entire Recycle Bin can be exported via a single command.

Situation description

All documents currently in the Recycle Bin should be exported from Input Management.

Prerequisites

Note
The CLI is designed as a development and administration tool and is not intended for delivery to end customers. Use at your own risk.

Procedure

1. Prepare the CLI

After downloading the CLI package, extract the ZIP archive.

The included appsettings.json file must then be modified in a text editor to reference the correct tenant. The hostname configured for both Authority and ServiceUrl must be replaced with the customer-specific tenant domain.

Note
Ensure that both Authority and ServiceUrl point to the correct tenant. If these settings are not configured correctly, authentication and export operations will fail.

2. Authenticate

Before exporting documents, the user must authenticate to obtain valid credentials:

STP.IM.Service.Cli.exe login

A help message will be displayed in the console. Open the link contained in the message in a web browser. The login page will display the requested permissions. Complete the sign-in process to continue.

3. Export the Recycle Bin

After successful authentication, run the following command:

STP.IM.Service.Cli.exe export-recycle-bin

It is possible to specify a target path for the backup as the only parameter of this command:

STP.IM.Service.Cli.exe export-recycle-bin D:\my\recycle\bin\backup

Location of the exported documents

Specifying a target path is optional.

If no target path is specified, a subfolder named recycleBinExport is created in the current working directory.

Within this folder, a separate subfolder is created for each exported document. Each document folder contains the original file using the name under which it was originally uploaded.

In short

If the filename of imported bank statements contains the IBAN, it can be picked up automatically through a combination of ScanFolder and document class configuration. This requires at least version 26.06.15.2 of the STP.IM.DocumentCollector.

Situation description

Many customers receive account statements where the account IBAN is part of the filename, for example:

2025-11-13_BKA_DE01234567890123456789_EUR_000006_2025-11-13_0.pdf

This IBAN should be picked up directly in Input Management.

Prerequisite

At least version 26.06.15.2 of the STP.IM.DocumentCollector must be installed.

Procedure

1. Configure the ScanFolder

In the ScanFolder configuration for the directory where the files containing the IBAN in the filename are delivered, add the following setting:

{
  "IncludeOriginalFileName": true
}

This instructs the DocumentCollector to transfer the original filename to Input Management.

2. Configure the Document Class

In the configuration of the target document class (for example, Bank Statements – Deutsche Bank), add the target field for the IBAN (for example, InterestedPartyIBAN) and configure the default value:

%OriginalFilename%

Important

Note
The target field name must contain the term IBAN.

Example: - InterestedPartyIBAN ✔️ - Bankverbindung ❌

If the field name does not contain the term IBAN, the extraction will not be performed.

Why are documents without a class while they are being processed?

In short

While a document is being processed, it is expected to be without a class. If processing takes too long (currently max. 3 hours), it is aborted and the document ends up — still without a class — in the faulty documents. This behavior is correct.

Situation description

Documents that are currently being processed show no class. If processing takes too long, these documents are aborted and subsequently appear without a class in the faulty documents.

Cause

As long as documents are being processed, they are without a class.

If processing takes too long, it is automatically aborted: - current timeout: max. 3 hours - until recently: 12 hours

After an abort, the affected documents end up in the faulty documents — still without a class.

Solution

No action required. The described behavior corresponds to the correct system behavior.

Note
The processing timeout has been reduced from 12 hours to currently 3 hours. Documents without a class in the faulty documents therefore do not necessarily indicate an error, but may be the result of a regular processing abort due to a timeout.