> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Datenbankvalidierung: Warnungen und Skip-Codes

> Übersicht aller Warnungen zur Didit-Datenbankvalidierung: Skip-Codes, Teilübereinstimmungen, unerreichbare Register und fehlende Felder.

Didits Funktion [Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) gleicht Identitätsdaten mit maßgeblichen Personenstandsregistern ab – RENAPER (Argentinien), Receita Federal (Brasilien), Tribunal Electoral (Panama, biometrisch), Junta Central Electoral (Dominikanische Republik) und weiteren – abgerechnet pro erfolgreicher Abfrage ohne monatliche Mindestgebühren.

Wenn kein Dienst ausgeführt werden kann (erforderliche Felder fehlen oder sind fehlerhaft, Register nicht verfügbar), das Dokument selbst nicht geprüft werden kann (es enthält nicht die Kennung, die die konfigurierten Dienste benötigen – z. B. ein Reisepass ohne nationale ID-Nummer) oder das Gesamtergebnis nicht eindeutig ist (teilweise Übereinstimmung, keine Übereinstimmung), gibt die Funktion eine **Warnung** für die Sitzung aus. Wenn das Ausstellungsland im Workflow überhaupt nicht aktiviert ist, wird der Schritt stillschweigend ohne Warnung und ohne Berechnung übersprungen. Diese Seite dokumentiert jeden Warnungscode, was ihn auslöst und wie die Workflow-Reaktion konfiguriert wird.

## Übersicht

Warnungen werden sowohl in Workflow-Sitzungen als auch von der eigenständigen API (`POST /v3/database-validation/`) generiert. Alle fünf Risiken sind mit der Funktion `DATABASE_VALIDATION` gekennzeichnet, erscheinen im Bericht unter `database_validations[].warnings[]` und folgen der standardmäßigen Struktur des [Warnungsobjekts](https://docs.didit.me/de/reference/data-models.md#warnungsobjekt) (`feature`, `risk`, `additional_data`, `log_type`, `short_description`, `long_description`, `node_id`).

Es gibt keine festen automatischen Ablehnungsauslöser für die Datenbankvalidierung. Die beiden Übereinstimmungsergebnis-Risiken, das Risiko für abgelöste Dokumente und das Risiko „Nicht anwendbar“ sind einer **konfigurierbaren Aktion** (`DECLINE`, `REVIEW` oder `NO_ACTION`) zugeordnet; `COULD_NOT_PERFORM_DATABASE_VALIDATION` ist das einzige feste Verhalten – es setzt die Funktion immer auf **in Prüfung**.

## Konfigurierbare Risiken

| Einstellung | Risiko-Code | Verhalten |
| - | - | - |
| Aktion bei keiner Übereinstimmung | `DATABASE_VALIDATION_NO_MATCH` | `REVIEW` (Workflow-Standard) setzt die Funktion auf **in Prüfung**; `DECLINE` lehnt ab; `NO_ACTION` erfasst die Warnung, ohne den Status zu beeinflussen. Der Parameter `no_match_action` der eigenständigen API verwendet stattdessen standardmäßig `DECLINE`. |
| Aktion bei teilweiser Übereinstimmung | `DATABASE_VALIDATION_PARTIAL_MATCH` | `NO_ACTION` (Standard) erfasst die Warnung, ohne den Status zu beeinflussen; `REVIEW` setzt die Funktion auf **in Prüfung**; `DECLINE` lehnt ab. |
| Aktion bei keiner Übereinstimmung | `DATABASE_VALIDATION_DOCUMENT_SUPERSEDED` | Teilt sich die Einstellung **Aktion bei keiner Übereinstimmung** – es gibt keinen separaten Schalter. Das Register widersprach den übermittelten Daten, sodass eine Organisation, die bei Nicht-Übereinstimmung ablehnt, auch bei einem veralteten Nachweis ablehnt. |
| Aktion bei Nichtanwendbarkeit | `DATABASE_VALIDATION_NOT_APPLICABLE` | `NO_ACTION` (Standard) erfasst die Warnung, ohne den Status zu beeinflussen; `REVIEW` setzt die Funktion auf **in Prüfung**; `DECLINE` lehnt ab. Wird ausgelöst, wenn das Dokument überhaupt nicht geprüft werden kann – es enthält nicht die Kennung, mit der die konfigurierten Dienste die Abfrage durchführen (z. B. ein Reisepass ohne nationale ID-Nummer). |

Die konfigurierte Aktion steuert auch den `log_type` der Warnung: `DECLINE` → `error`, `REVIEW` → `warning`, `NO_ACTION` → `information`.

Das Übereinstimmungsergebnis selbst wird aus den `validation`-Einträgen pro Dienst aggregiert (mindestens eine vollständige Übereinstimmung → `full_match`; andernfalls mindestens eine teilweise → `partial_match`; andernfalls `no_match`) – siehe [Abgleichsmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md) für die vollständige Entscheidungslogik, die 1×1- / 2×2-Ergebnisse ableitet.

## Erzeugte Warnungen

| Tag | Kurzbeschreibung | Beschreibung |
| - | - | - |
| `COULD_NOT_PERFORM_DATABASE_VALIDATION` | Datenbankvalidierung konnte nicht durchgeführt werden | Kein Dienst hat ein verwertbares Ergebnis zurückgegeben (`match_type` bleibt `null`) – typischerweise, weil erforderliche Felder fehlen oder fehlerhaft formatiert sind oder das Register einen Fehler zurückgegeben hat. `additional_data` enthält die Zusammenfassung der Übersprünge pro Dienst (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); die eigenständige API verwendet stattdessen `{ "validation_errors": [...] }`. **Ihnen werden keine Kosten berechnet**, wenn diese Warnung ausgelöst wird; die Funktion wechselt auf **In Prüfung**, bis die Daten korrigiert sind. |
| `DATABASE_VALIDATION_NOT_APPLICABLE` | Datenbankvalidierung für dieses Dokument nicht anwendbar | Das vorgelegte Dokument enthält nicht die Kennung, die die konfigurierten Datenbankdienste erfordern (`match_type` bleibt `null`) – beispielsweise enthält ein brasilianischer Reisepass keine CPF, sodass das CPF-Register nicht abgefragt werden kann. Dies wird für den Dokumenttyp erwartet und weist nicht auf ein Problem mit dem Dokument hin. `additional_data` enthält die Zusammenfassung der Übersprünge pro Dienst. **Ihnen werden keine Kosten berechnet**, wenn diese Warnung ausgelöst wird. Aktion konfigurierbar (Standardwert `NO_ACTION`). |
| `DATABASE_VALIDATION_PARTIAL_MATCH` | Teilweise Übereinstimmung bei Datenbankvalidierung | Der aggregierte `match_type` ist `partial_match` – einige überprüfte Felder stimmten mit dem Register überein, aber nicht alle. Aktion konfigurierbar (Standardwert `NO_ACTION`). |
| `DATABASE_VALIDATION_NO_MATCH` | Keine Übereinstimmung bei Datenbankvalidierung | Der aggregierte `match_type` ist `no_match` – das Register konnte die geprüfte Identität nicht bestätigen. Aktion konfigurierbar (Standardwert `REVIEW` in Workflows, `DECLINE` in der eigenständigen API). |
| `DATABASE_VALIDATION_DOCUMENT_SUPERSEDED` | Ersetzte Dokumentversion | Ein Dienst hat `DOCUMENT_SUPERSEDED` zurückgegeben: Das Register hat die Person bestätigt, aber die vorgelegte Version des Dokuments ist nicht die hinterlegte – inzwischen wurde eine neuere Version ausgestellt. Wird unabhängig von `match_type` ausgelöst, der auf `full_match` bleibt, da jedes persönliche Feld übereinstimmte, sodass der Befund andernfalls unsichtbar bliebe. `additional_data` benennt die Dienste, die dies gemeldet haben. Folgt der Einstellung **No Match Action**. |

> [!NOTE]
>
> `COULD_NOT_PERFORM_DATABASE_VALIDATION` deckt zwei verschiedene Situationen ab, und die `long_description` der Warnung (sowie bei einem dienstspezifischen Fehler `database_validation_errors[].message`) gibt nun an, welche Situation zutraf, anstatt einen einzelnen generischen Satz zu verwenden: Die geprüften Daten fehlten oder waren fehlerhaft formatiert, bevor ein Dienst abgefragt werden konnte, oder ein Dienst wurde abgefragt und lieferte kein verwertbares Ergebnis. Im zweiten Fall gilt: Wenn das Register für diesen Versuch eigene Diagnosedetails gemeldet hat, sind diese Details in der Nachricht enthalten, sodass Sie sich nicht an den Support wenden müssen, um den Grund zu erfahren. Der vorgeschaltete Dienst wird in der Antwort niemals namentlich genannt.

> [!NOTE]
>
> Wenn `COULD_NOT_PERFORM_DATABASE_VALIDATION` oder `DATABASE_VALIDATION_NOT_APPLICABLE` in einer Workflow-Sitzung ausgelöst wird, wird die Prüfung automatisch erneut angestoßen, sobald die fehlenden Daten auf der Sitzungsdetailseite in der Konsole ausgefüllt werden – das Speichern des Feldes führt die Validierung erneut aus, und die Warnung wird bei Erfolg entfernt. Dies funktioniert auch, wenn die Aktion für „nicht anwendbar“ die Sitzung abgelehnt hat, sodass eine abgelehnte Sitzung durch Korrektur der Daten behoben werden kann. Bei `DATABASE_VALIDATION_NOT_APPLICABLE` hilft die erneute Ausführung, wenn das Dokument die Kennung enthalten kann, diese jedoch nicht gelesen wurde (beispielsweise ein Aufenthaltstitel, dessen nationale Ausweisnummer nicht extrahiert wurde); bei Dokumenttypen, die die Kennung grundsätzlich nicht enthalten (beispielsweise Reisepässe ohne nationale Ausweisnummer), bleibt die Warnung bestehen. **Keine Kosten** fallen für übersprungene Dienste an; Sie zahlen nur, wenn ein Dienst ein abrechenbares Ergebnis liefert.

## Beispiel

```json theme={null}
{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}
```

## Warnungstypen

Jedem Risiko wird basierend auf der Konfiguration Ihrer Anwendung ein Schweregrad zugewiesen. Die Schweregrade fallen in drei Kategorien:

## Verwandte Themen

* [Übersicht zur Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/overview.md) – Funktionsweise von Anfang bis Ende und unterstützte Register.
* [Bericht zur Datenbankvalidierung](https://docs.didit.me/de/core-technology/database-validation/database-validation-report.md) – vollständige Antwortstruktur einschließlich dienstspezifischer `validations[]`.
* [Abgleichsmethoden](https://docs.didit.me/de/core-technology/database-validation/database-validation-matching-methods.md) – wie 1×1- / 2×2-Ergebnisse (`validation_type: one_by_one` / `two_by_two`) aus dienstspezifischen Abgleichen abgeleitet werden.
* [Ergebniscodes](https://docs.didit.me/de/core-technology/database-validation/database-validation-outcome-codes.md) – vollständige Taxonomie pro Ergebnis mit länderspezifischen Detailcodes.
* [Unterstützte Länder und Dienste](https://docs.didit.me/de/core-technology/database-validation/database-validation-supported-countries.md) – alle produktiven Register, erforderliche Felder und Preis pro Aufruf.
* [Datenmodelle – Datenbankvalidierung](https://docs.didit.me/de/reference/data-models.md#datenbankvalidierung) – kanonisches Feld-für-Feld-Schema.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.