eSchKG 2.0 Best Practice - sanitycheck.ch · eSchKG 2.0 Best Practice (Green Book) | Vorab-Version...

Eidgenössisches Justiz- und Polizeidepartement EJPD

Bundesamt für Justiz BJ

Direktionsbereich Zentrale Dienste

Fachbereich Rechtsinformatik

Green Book

eSchKG 2.0 Best Practice

Vorab-Version

Austausch von elektronischen Geschäftsdaten im Schuld-betreibungs- und Konkurswesen

Version 0.97.02 / 03.10.2014

eSchKG 2.0 Best Practice (Green Book) | Vorab-Version (0.97) | 03.10.2014 Seite 2

Inhaltsverzeichnis

Über das Green Book ....................................................................................................................................... 5

Dokumentstruktur ........................................................................................................................................... 5

Projektinformation im Internet ........................................................................................................................ 5

Teil I Best Practice ........................................................................................................................................... 6

1 Allgemeine Hinweise ............................................................................................................................... 7

1.1 eSchKG im Betrieb ............................................................................................................................ 7 1.1.1 Aktive Überwachung des Datenverkehrs ....................................................................................... 7 1.1.2 Pilot- oder Versuchsbetrieb........................................................................................................... 7 1.1.3 Erneuerung der digitalen Zertifikate und Schlüssel von Sedex ........................................................ 8 1.1.4 Digitale Signatur auf PDF-Beilagen anbringen .............................................................................. 8 1.1.5 Digitale Signatur auf PDF-Beilagen verifizieren ............................................................................. 9 1.1.6 Verbundsteuerung über das Teilnehmerverzeichnis (Member Directory) ....................................... 9 1.1.7 Teilnehmerverzeichnis Version 1.1a ............................................................................................ 10 1.1.8 Teilnehmerverzeichnis Version 2.0 .............................................................................................. 10 1.1.9 Download des Teilnehmerverzeichnisses 2.0 ............................................................................... 11 1.1.10 Meldungsrhythmus .................................................................................................................... 11 1.1.11 Priorisierter Empfang von Meldungen ........................................................................................ 11 1.1.12 Vom MessageHandler abweichende Middleware ........................................................................ 11 1.1.13 Einrichten von Sedex und MessageHandler ................................................................................. 12 1.1.14 Verwendung des Datenfeldes usage ........................................................................................... 12

2 Best Practice für Gläubiger..................................................................................................................... 13

2.1 Vor der Inbetriebnahme ................................................................................................................. 13 2.1.1 Qualitätssicherung der eSchKG Software .................................................................................... 13 2.1.2 Bereitschaftsmeldung an das Bundesamt für Justiz BJ ................................................................. 13

2.2 Einreichen von elektronischen Begehren ........................................................................................ 14 2.2.1 Einreichung nach Reorganisation (Zusammenlegung, Ämterfusion) ............................................ 14 2.2.2 Signierte Dokumente eines Betreibungsamtes weiterverwenden ................................................. 14 2.2.3 Änderungen an den Gläubiger-Stammdaten und Auswirkung auf credId ..................................... 15 2.2.4 Verwendung von actorId ............................................................................................................ 15 2.2.5 Verwendung von actorIdOffice ................................................................................................... 16 2.2.6 Verwendung von senderRefData ................................................................................................ 16 2.2.7 Verwendung von caseNumber .................................................................................................... 16 2.2.8 Verwendung von caseDetails im Betreibungsbegehren (CR Meldung).......................................... 17 2.2.9 Neuerliche Einreichung eines Betreibungsbegehrens nach gescheiterter Übertragung ................. 17 2.2.10 Verwendung von collocation (CR oder CC Meldung) .................................................................... 17 2.2.11 Neuerliche Einreichung eines Betreibungsbegehrens (CR Meldung) nach expliziter Rückweisung durch das Amt ........................................................................................................................................ 18 2.2.12 Forderungen im Betreibungsbegehren (CR Meldung) eingeben ................................................... 18 2.2.13 Zinsen auf Forderungen .............................................................................................................. 19 2.2.14 Fortsetzungsbegehren (CC Meldung) im Modus "original" einreichen .......................................... 19 2.2.15 Fortsetzungsbegehren (CC Meldung) im Modus "modified" einreichen ........................................ 19 2.2.16 Fortsetzungsbegehren (CC Meldung) im Modus "novel" einreichen ............................................. 20 2.2.17 Mehrauslagen im Fortsetzungsbegehren anmelden .................................................................... 20 2.2.18 Verwertungsbegehren (RR Meldung) einreichen ......................................................................... 20 2.2.19 Auskunftsbegehren stellen (DI Meldung) .................................................................................... 21

2.3 Empfang/Lesen von Meldungen des Betreibungsamtes .................................................................. 21 2.3.1 Fachliche Antwort und Fehleranzeige in der SA Meldung ............................................................ 21 2.3.2 Anzahl zu erwartende Kopien des Doppels des Zahlungsbefehls .................................................. 21 2.3.3 Anzahl zu erwartende Kopien der Konkursandrohung ................................................................. 22


2.3.4 Kostenangaben in Abschlussmeldungen ..................................................................................... 22 2.3.5 Ergebnis der Fortsetzung verstehen ............................................................................................ 22 2.3.6 Ergebnis der Pfändung verstehen ............................................................................................... 23 2.3.7 RC Meldung empfangen ............................................................................................................. 23

2.4 Personen und Adressen .................................................................................................................. 23 2.4.1 Gläubiger und Gläubigervertreter ............................................................................................... 23 2.4.2 Wenn mehr als ein Gläubiger existiert ........................................................................................ 24 2.4.3 Wenn mehr als ein Gläubigervertreter existiert ........................................................................... 24 2.4.4 Personenangaben richtig erfassen .............................................................................................. 24 2.4.5 Adressangaben richtig erfassen .................................................................................................. 25 2.4.6 Schuldnervertreter und Mitbetriebene ........................................................................................ 25

2.5 Beilagen (External Documents) ....................................................................................................... 25 2.5.1 Elektronische Unterschrift für Beilagen ....................................................................................... 25 2.5.2 Titel des Dokuments richtig erfassen .......................................................................................... 26 2.5.3 Rechtzeitiger Versand von Dokumenten ..................................................................................... 26 2.5.4 Format von Beilagen .................................................................................................................. 26

2.6 Zahlungseingänge melden .............................................................................................................. 27 2.6.1 Zahlungen mit der PN Meldung anzeigen ................................................................................... 27 2.6.2 Zahlungsmeldung vs. Betreibung bezahlt .................................................................................... 27

2.7 Fallsteuerung und Statusabfrage (SR) ............................................................................................. 27 2.7.1 Statusabfrage ............................................................................................................................ 27 2.7.2 Betreibung beenden ................................................................................................................... 28 2.7.3 Letztmaliges Begehren rückgängig machen ................................................................................ 28 2.7.4 Betreibung zurückziehen ............................................................................................................ 28

2.8 Spezialmeldung .............................................................................................................................. 29 2.8.1 Empfangsbereitschaft für die SN Meldung .................................................................................. 29 2.8.2 Eignung von Spezialmeldungen .................................................................................................. 29

2.9 Elektronisches Teilnehmerverzeichnis ............................................................................................ 29 2.9.1 Amts-Identifikationsnummer ...................................................................................................... 29 2.9.2 Typisierung der Teilnehmer ........................................................................................................ 30 2.9.3 Teilnehmerverzeichnis mittels SN Meldung empfangen............................................................... 30

3 Best Practice für Betreibungsämter ....................................................................................................... 31

3.1 Entgegennahme von Daten ............................................................................................................ 31 3.1.1 Gläubiger-Stammdaten und credId ............................................................................................. 31 3.1.2 Zahlstelle des Gläubigers oder Vertreters .................................................................................... 31 3.1.3 Angaben in Kommentaren .......................................................................................................... 31 3.1.4 Daten übernehmen wie eingereicht ............................................................................................ 32

3.2 Empfang von elektronischen Beilagen ............................................................................................ 32 3.2.1 Prüfung von Dokumenten des Gläubigers ................................................................................... 32 3.2.2 Anerkennen von Dokumenten anderer Ämter ............................................................................. 32 3.2.3 Prüfung von digital signierten Dokumenten anderer Ämter ......................................................... 33

3.3 Antwortmeldung SA ...................................................................................................................... 33 3.3.1 Fachliche Quittung ..................................................................................................................... 33 3.3.2 Keine SA Meldung ausserhalb der Sequenz ................................................................................. 34 3.3.3 Fehlermeldung vs. Rückweisung ................................................................................................. 34 3.3.4 Nicht reagieren .......................................................................................................................... 34

3.4 Versand von elektronischen Beilagen ............................................................................................. 34 3.4.1 Referenzierte Beilagen tatsächlich versenden ............................................................................. 34

3.5 Betreibungsauszug ......................................................................................................................... 35 3.5.1 Angaben zu Konkursen und Konkursverlustscheinen ................................................................... 35 3.5.2 Zurückgezogene Betreibungen ................................................................................................... 35

3.6 Kosten melden ............................................................................................................................... 35 3.7 Barcodes auf Betreibungsurkunden ................................................................................................ 36

Teil II .............................................................................................................................................................. 37

Fallbeispiele ................................................................................................................................................... 37


Teil III eSchKG Management Prozesse ........................................................................................................... 38

4 eSchKG-Prozesse des Gläubigers ............................................................................................................ 39

4.1 Prozesse gemäss Orange Book ....................................................................................................... 39 4.2 Bestellung eines Sedex Anschlusses für den eSchKG Verbund ......................................................... 39 4.3 Prüfungen mit dem eSchKG Testbed ............................................................................................... 40 4.4 Sanity Check ................................................................................................................................... 40 4.5 QA Prüfung mit dem Bundesamt für Justiz ...................................................................................... 40

4.5.1 Was bedeutet QA Prüfung? ........................................................................................................ 40 4.5.2 Rahmenbedingungen ................................................................................................................. 40 4.5.3 Steuerung mittels Szenario-Code ................................................................................................ 41

4.6 Bereitschaftsmeldung an das Bundesamt für Justiz ......................................................................... 43 4.6.1 Abschliessende Verifikation durch das BJ .................................................................................... 43 4.6.2 Empfangsbereitschaft für Meldungen des BJ .............................................................................. 43

5 eSchKG-Prozesse des Betreibungsamtes ................................................................................................ 44

5.1 Bereitschaftsmeldung an das Bundesamt für Justiz ......................................................................... 44 5.1.1 Anmeldung durch den Softwarelieferanten ................................................................................. 44 5.1.2 Abschliessende Verifikation durch das BJ .................................................................................... 44 5.1.3 Empfangsbereitschaft für Meldungen des BJ .............................................................................. 44

5.2 Pflicht zur Entgegennahme von SN Meldungen ............................................................................... 45 5.3 Versand von SN Meldungen ........................................................................................................... 45 5.4 Teilnehmerverzeichnis einlesen ...................................................................................................... 45 5.5 Statistikabfragen des Bundesamtes für Justiz .................................................................................. 45

6 eSchKG-Prozesse des BJ ......................................................................................................................... 46

6.1 Bereitschaftsmeldung eines Betreibungsamtes ............................................................................... 46 6.2 Bereitschaftsmeldung eines Gläubigers .......................................................................................... 46 6.3 Publikation des Teilnehmerverzeichnisses im Internet .................................................................... 47 6.4 Versand des Teilnehmerverzeichnisses mittels SN .......................................................................... 47 6.5 Ämterzusammenlegung / Fusion .................................................................................................... 47 6.6 Fusion von Gläubigern .................................................................................................................... 48


Über das Green Book

Der eSchKG Standard ist in einer Reihe von Normenhandbüchern niedergeschrieben:

Einführung in den eSchKG Standard (White Book);

Exchange of Electronic Business Information in the Domain of Debt Enforcement and Bankruptcy, inkl. Anhänge (Blue Book);

eSchKG Networking (Red Book);

Anleitung für die Mitgliedschaft im eSchKG Verbund (Orange Book).

Das vorliegende Dokument ist das Ergebnis von mehreren Jahren Erfahrung mit eSchKG. Es hat zum Ziel, einen reibungslosen Austausch von Betreibungsdaten zu fördern, indem es auf mögliche Problemfelder, häufige Fehlerquellen und deren Vermeidung hinweist.

Dokumentstruktur

Das Green Book ist in drei Teile gegliedert.

Teil I: Best Practice. Dieser Teil umfasst vorwiegend technische Hinweise für die

Teilnehmer des eSchKG Verbundes, um eSchKG nutzbringend und effizient einzu-setzen;

Teil II: Fallbeispiele.

Teil III: eSchKG Management Prozesse. Die administrativen Belange rund um

eSchKG, wie Bereitschaftsmeldung, Testverfahren und mehr.

Projektinformation im Internet

Informationen über das Projekt eSchKG, den Standard eSchKG, die technischen Hilfsmittel sowie sämtliche Handbücher finden sich auf der offiziellen Website unter www.eschkg.ch.


Teil I Best Practice


1 Allgemeine Hinweise

1.1 eSchKG im Betrieb

1.1.1 Aktive Überwachung des Datenverkehrs

Kontext Der Austausch von Betreibungsinformationen erfolgt über das Kopieren von XML-Dateien im Filesystem. Werden keine speziellen Massnahmen getroffen, so hat die Fachanwendung keinerlei Übersicht über die via Sedex tatsächlich zugestellten Meldungen. Bei Problemen mit der Übertragung kann die Folge sein, dass längere Zeit nicht bemerkt wird, wenn Meldungen nicht zugestellt werden konnten oder der Meldungsversand gar zum Erliegen gekommen ist.

IT / Prozesse Von den Sedex-Spezialitäten braucht die Fachanwendung nichts zu wissen, der MessageHandler (MH) erledigt alles. Die Webservice-Schnittstelle des MH er-laubt die Kontrolle und Überwachung des Datenverkehrs. Einzelheiten finden sich in der Dokumentation OE MessageHandler v3.

Best Practice Die Funktion des MH ist regelmässig zu überwachen (PING Service);

Eine Prüfroutine (separat oder als Teil der Fachanwendung) sollte den Status von ausgehenden Meldungen regelmässig überprüfen und si-cherstellen, dass die Meldungen beim Sedex-Hub angekommen resp. beim Empfänger zugestellt worden sind;

Die Organisation sollte Notfallszenarien bereit halten und auf Probleme reagieren können, insbesondere wenn der Versand über längere Zeit nicht möglich sein sollte. Der mögliche Ausfall der Meldungsübermittlung im Rahmen von eSchKG sollte Teil des Incident Managements sein.

1.1.2 Pilot- oder Versuchsbetrieb

Kontext Zwischen Sommer 2013 und Frühjahr 2014 hat die Projektleitung eine Pilotie-rung auf Basis von eSchKG 2.0 Revision 013 durchgeführt, an der einige wenige Gläubiger und Betreibungsämter teilgenommen hatten.

IT / Prozesse Gläubiger, welche eSchKG 2.0 schrittweise einführen möchten, haben die Mög-lichkeit, einen Versuchsbetrieb durchzuführen. Sie erhalten jedoch keine aktive Unterstützung von Seiten der Projektleitung, z.B. durch Zusendung eines sepa-raten Teilnehmerverzeichnisses. Ausserdem müssen sie so vorgehen, dass die Betreibungsämter, mit denen eSchKG-Daten ausgetauscht werden, normal ar-beiten können. Kein Betreibungsamt braucht Kenntnis davon zu haben (und soll es auch nicht), wenn ein Gläubiger eSchKG im Versuchsbetrieb einsetzt. Jeder Versuchsbetrieb ist ein normaler produktiver Betrieb mit Einschränkungen, die sich der Gläubiger selber auferlegt, z.B. indem er nur mit einer kleinen Anzahl Betreibungsämtern eSchKG-Daten austauscht.

Best Practice Wer einen Versuchsbetrieb durchführen will, muss ein vollwertiger Teil-nehmer des eSchKG-Verbundes sein;

Auch während eines Versuchsbetriebs werden ausschliesslich produkti-ve eSchKG-Daten verwendet;

Es dürfen keine Testdaten an Betreibungsämter verschickt werden!


1.1.3 Erneuerung der digitalen Zertifikate und Schlüssel von Sedex

Kontext Sedex bildet die technologische Grundlage des eSchKG-Verbundes. Daten wer-den verschlüsselt und signiert übermittelt, weshalb digitale Schlüssel und Zertifi-kate benötigt werden. Diese erhält der Teilnehmer am Anfang seiner Mitglied-schaft im eSchKG-Verbund durch das Bundesamt für Statistik resp. Bundesamt für Informatik & Telekommunikation BIT zugestellt.

IT / Prozesse Das Schlüsselmaterial und das Zertifikat des (physischen) Sedex-Anschlusses werden durch die Sedex-Software bei Bedarf automatisch erneuert. Jene von logischen Teilnehmern sind, soweit es den Datenaustausch mit Sedex betrifft, unbedeutend; sie wurden schon bei der Installation des Sedex-Anschlusses nicht verwendet, da der Meldungsfluss über den physischen Sedex-Anschluss erfolgt, wo er auch signiert und verschlüsselt wird.

Best Practice Teilnehmer sollten nach Möglichkeit einen separaten physischen Sedex-Anschluss haben;

Teilnehmer, die das Schlüsselmaterial und die digitalen Zertifikate ihres logischen Sedex-Anschluss verwenden, sollten ein Erinnerungsmana-gement für die Erneuerung des Schlüsselmaterials und der digitalen Zertifikate ihres logischen Anschlusses durchführen;

Sind das Schlüsselmaterial und die digitalen Zertifikate manuell ersetzt worden, so sind danach Verbindungs- und Funktionstests durchzufüh-ren, bevor der produktive Betrieb wiederaufgenommen wird.

1.1.4 Digitale Signatur auf PDF-Beilagen anbringen

Kontext Teilnehmer mit einem physischen Sedex-Anschluss verwenden die Schlüssel und Zertifikate unter anderem für die digitale Signatur von PDF-Beilagen. Das gilt im Prinzip nur für Betreibungsämter, da Gläubiger keine Notwendigkeit be-steht, PDF-Beilagen zu signieren.

IT / Prozesse Teilnehmer mit einem logischen Sedex-Anschluss verwenden zur digitalen Sig-nierung das Schlüsselmaterial und Zertifikat ihres logischen Anschlusses. Diese digitalen Mittel, welche ausschliesslich der digitalen Signatur dienen, werden von der Sedex-Software nicht automatisch erneuert und müssen vom Teilnehmer manuell aktualisiert werden. Inhaber eines logischen Sedex-Anschlusses müs-sen sich daher selber um die Erneuerung des Schlüsselmaterials und der Zertifi-kate kümmern, soweit es die digitale Signatur anbelangt (Für den Sedex-Datenverkehr müssen weiterhin keine separaten Massnahmen getroffen wer-den, da dieser über den physischen Sedex-Anschluss erfolgt).

Best Practice Die Teilnehmer sollten nach Möglichkeit einen physischen Sedex-Anschluss für eSchKG haben;

Gläubiger sollen Beilagen nicht signieren.


1.1.5 Digitale Signatur auf PDF-Beilagen verifizieren

Kontext Eine digitale Signatur auf ihre Gültigkeit hin zu überprüfen ist ein komplexer Vor-gang, der normalerweise von einer eingebauten Verifikationsfunktion erledigt wird, z.B. im Adobe Reader.

Damit die Signatur verifiziert werden kann, muss Adobe Reader die Zertifikate resp. deren Herausgeber kennen. Weil dem Adobe Reader die Sedex-Zertifikate des eSchKG-Verbundes nicht bekannt sind, wird er die Echtheit der Signatur nicht vollständig nachweisen können und einen Warnhinweis anzeigen.

Die nötige Konfiguration des Readers, um eSchKG-Beilagen korrekt zu prüfen, kann umfangreich und komplex werden. Ausserdem wären sämtliche Reader bei allen potentiellen Empfängern von PDF-Beilagen entsprechend zu konfigurieren.

IT / Prozesse Es gibt eine Prüfstelle für signierte eSchKG-Beilagen im Internet. Die Beilage wird im Browser hinauf geladen, worauf hin ein Prüfbericht angezeigt wird.

Best Practice Bei Unsicherheiten betreffend der digitalen Signatur kann der eSchKG-Signaturvalidator verwendet werden. Hinweis per 1.10.2014: Der Validator ist in Arbeit.

1.1.6 Verbundsteuerung über das Teilnehmerverzeichnis (Member Directory)

Kontext Das eSchKG-Teilnehmerverzeichnis enthält Kontaktangaben und technische Adressinformationen aller Teilnehmer, um im Rahmen von eSchKG erreichbar zu sein.

IT / Prozesse Die Teilnehmer werden via Email über Änderungen im Verzeichnis informiert. eSchKG 2.0-Teilnehmer erhalten das Verzeichnis zudem via SN Meldung.

Best Practice Die eSchKG-Regeln besagen, dass nur jene eSchKG-Meldungen annehmen und versenden dürfen, die aktive Mitglieder gemäss Teilnehmerverzeichnis sind (eSchKG Member Directory). Konkret:

Meldungen von deaktivierten oder nicht aufgeführten Teilnehmern müs-sen ignoriert werden. Insbesondere dürfen keine eSchKG-Meldungen als Reaktion auf die ungültige Meldung zurückgesandt werden;

Meldungen dürfen nur an aktive Teilnehmer versendet werden;

Bei Problemen mit dem Einlesen des Verzeichnisses darf der Teilneh-mer bis zur Behebung keine eSchKG Meldungen versenden;

Es ist sicherzustellen, dass immer die neuste Ausgabe des Teilnehmer-verzeichnisses passend zur eSchKG-Version verwendet wird. Dieses liegt zum Download in der eSchKG Homepage bereit. Das Verzeichnis 2.0 wird zudem an alle Teilnehmer via SN Meldung verschickt.


1.1.7 Teilnehmerverzeichnis Version 1.1a

Kontext eSchKG 1.1a und 2.0 verwenden unterschiedliche Verzeichnisformate und -inhalte. Das Verzeichnis für eSchKG 1.1a wird in den Formaten Excel 97-2003 (.xls) und Tab-delimited Text (.txt) angeboten.

IT / Prozesse Da das Teilnehmerverzeichnis aktive und deaktivierte Teilnehmer enthält, ist die Kombination aus Aktivierungsdatum ADATE und Deaktivierungsdatum DDATE entscheidend. Es gilt: Aktiv ↔ (ADATE < today) UND (DDATE > today [resp. leer])

Best Practice Die Anwendungsarchitektur sollte es erlauben, das Teilnehmerverzeich-nis im laufenden Betrieb neu zu laden (Aktualisierung);

Wenn ein Amt, mit dem ein laufendes Verfahren besteht, in ein anderes fusioniert wird, so wird dieses im Verzeichnis deaktiviert (DDATE). In diesem Fall ist das neue zuständige Amt zu ermitteln und die Betreibung mit diesem weiterzuführen (vgl. auch Ämterfusion 2.2.1).

1.1.8 Teilnehmerverzeichnis Version 2.0

Kontext eSchKG 1.1a und 2.0 verwenden unterschiedliche Verzeichnisformate und -inhalte. Das Verzeichnis für eSchKG 2.0 wird in den Formaten Excel 2007 (.xlsx) und Text (.csv, Semikolon-getrennt) angeboten.

IT / Prozesse Das Teilnehmerverzeichnis 2.0 enthält ausschliesslich aktive Teilnehmer (es gibt keine DDATE-Spalte wie in Version 1.1a). Der Dateiname ist sprechend und codiert den Zeitpunkt, ab dem das Verzeichnis gültig ist. Alle Betreibungsämter sind eSchKG 1.1a-fähig. Steht im Verzeichnis in der Spal-te VER eine "2", so ist das Betreibungsamt zusätzlich 2.0-fähig. Die Teilnehmer werden via Email über Änderungen informiert. Das Teilnehmer-verzeichnis Version 2.0 steht in der eSchKG Homepage zum Download bereit, zudem wird es nach einer Änderung an alle 2.0-fähigen Teilnehmer via SN Mel-dung verschickt.

Best Practice In der Praxis reicht die Prüfung auf Existenz des Eintrags im Teilneh-merverzeichnis aus (Spalte ID_LOG);

Die Anwendungsarchitektur sollte es erlauben, das Teilnehmerverzeich-nis im laufenden Betrieb zu aktualisieren, vorzugsweise automatisiert nach Erhalt der SN Meldung;

Die Aktualisierung hat auf das Datum zu erfolgen, das gemäss Na-menskonvention im Dateinamen codiert ist;

Die Zeitangabe im Timestamp des Dateinamens dient zur Unterschei-dung von Verzeichnissen, die am gleichen Tag erzeugt wurden. Bei gleichlautendem Gültigkeitsdatum ist das jüngere Verzeichnis zu ver-wenden. Beispiel: Die Files …20140822T020000.csv und

…20140822T000000.csv zeigen denselben Tag an. Zu verwenden ist

das erste, weil es eine spätere Zeitangabe hat (es ist das jüngere);

Wenn ein Amt, mit dem ein laufendes Verfahren besteht, in ein anderes fusioniert wird, so wird dieses aus dem Verzeichnis gelöscht (Zukünftige Versionen des Verzeichnisses werden das Amt nicht mehr führen). In diesem Fall ist das neue zuständige Amt zu ermitteln und die Betreibung mit diesem weiterzuführen (vgl. auch Ämterfusion 2.2.1).


1.1.9 Download des Teilnehmerverzeichnisses 2.0

Kontext Das jeweils aktuelle Teilnehmerverzeichnis für eSchKG 2.0 steht in beiden For-maten als Download auf der eSchKG Homepage bereit.

IT / Prozesse Der Speicherort des aktuellen Teilnehmerverzeichnisses hängt vom Format ab: Excel-2007-Format: http://www.eschkg.ch/downloads/2.0/xlsx

CSV (Text) Format: http://www.eschkg.ch/downloads/2.0/csv

Das Verzeichnis wird täglich um 02:00 aktualisiert. Da es sich um das jeweils aktuelle Teilnehmerverzeichnis handelt, hat es unmittelbare Gültigkeit. (Dies ist u.a. daran zu erkennen, dass der Zeitstempel im Dateinamen nie in der Zukunft liegt.)

Best Practice Wenn das Teilnehmerverzeichnis nicht per SN Meldung verarbeitet wird, sollte es täglich von dem oben angegebenen Speicherort heruntergeladen und in die eSchKG-Software eingelesen werden.

1.1.10 Meldungsrhythmus

Kontext Der Meldungsaustausch mit Sedex und MessageHandler ist von betrieblichen Konfigurationen abhängig. Diese beeinflussen die Häufigkeit des Meldungsab-rufs resp. -versandes. Der Versand und Empfang von eSchKG-Meldungen hat mindestens einmal täglich zu erfolgen.

IT / Prozesse Die Konfiguration für den MessageHandler beinhaltet Optionen, mit denen der Empfangs- und Versandrhythmus festgelegt werden können. Einzelheiten dazu finden sich im eSchKG Red Book und im Sedex Handbuch.

Best Practice Die Sedex Inbox (Empfang) und Outbox (Versand) sollten mehrmals täglich geleert werden, z.B. stündlich.

1.1.11 Priorisierter Empfang von Meldungen

Kontext Meldungen des Bundesamts für Justiz geniessen höhere Priorität.

IT / Prozesse Meldungen sind grundsätzlich nach dem First-Come-First-Serve Prinzip zu ver-arbeiten. SN-Meldungen des Bundesamts für Justiz müssen unmittelbar nach Erhalt behandelt werden, da sie wichtige Steuerungs- und andere Informationen enthalten können.

Best Practice SN-Meldungen des BJ sind dem Benutzer unmittelbar zur Kenntnis zu bringen.

1.1.12 Vom MessageHandler abweichende Middleware

Kontext Die MessageHandler Software ist die bevorzugte Middleware, um die Anwen-dung vor der Sedex-Komplexität abzuschirmen. Sie erledigt die Paketierung, den Meldungsversand und bietet Überwachungsfunktionen.

IT / Prozesse Das Bundesamt für Justiz kümmert sich um die Weiterentwicklung und Wartung der MessageHandler Software und bietet Unterstützung für die Teilnehmer des eSchKG Verbundes. Wer eine andere Middleware einsetzt, muss in der Lage sein, Meldungen des übrigen Verbundes zu lesen und eigene Meldungen so zu produzieren, dass sie von allen übrigen Akteuren gelesen werden können.

Best Practice Die Kombination Sedex/MessageHandler wird vom Projekt aktiv unterstützt. Es wird kein Support für andere Middlewareprodukte angeboten.


1.1.13 Einrichten von Sedex und MessageHandler

Kontext Sedex und MessageHandler sind die relevanten Bausteine zur Realisierung des Datentransports im eSchKG Verbund.

IT / Prozesse Einrichten bedeutet, Software für Sedex und MessageHandler zu installieren und zu konfigurieren. Die relevanten Informationen sind im eSchKG Red Book und in den Sedex-Handbüchern zu finden.

Best Practice Beim Installieren und Einrichten ist wie folgt vorzugehen: 1. Zuerst den Sedex-Anschluss installieren ("Sedex Client") und die im Se-

dex-Handbuch beschriebenen Verbindungstests durchführen; 2. Danach die MessageHandler Software installieren und konfigurieren. 3. MessageHandler bei ausgeschaltetem Sedex-Anschluss testen: Ver-

sandtests (Adressierung, Sedex-Umschlag, Weiterleitung an die Sedex-OUTBOX) und Empfangstests insb. bei mehreren INBOXen aufgrund von logischen Teilnehmern;

4. Sedex-Anschluss einschalten und kombinierten Test mit dem Testbed durchführen: XML-Testdaten aus dem eSchKG Testbed verwenden.

1.1.14 Verwendung des Datenfeldes usage

Kontext Das XML-Datenfeld document/envelope/transactionInfo/usage zeigt

an, mit welcher Absicht die Datenübertragung erfolgt, entweder für Tests oder den produktiven Datenaustausch.

IT / Prozesse Für den täglichen produktiven Datenverkehr ist der Wert production zu ver-

wenden. Der Wert test darf ausschliesslich für Funktions- und Konformitäts-

tests mit dem eSchKG Testbed und allenfalls für Tests mit den Herstellern von Betreibungssoftware eingesetzt werden (vgl. Orange Book).

Best Practice Vor der Aufschaltung als aktives Mitglied (vor Bereitschaftsmeldung gem. Orange Book) darf der Teilnehmer nur test verwenden;

Für den selbst-organisierten Versuchsbetrieb, z.B. im Sinne einer Pilo-tierung mit wenigen Betreibungsämtern, ist production zu verwenden;

Wer einen selbst-organisierten Versuchsbetrieb durchführt, handelt ge-genüber den Betreibungsämtern wie ein normaler produktiver Teilneh-mer. Kein Amt soll wissen müssen, dass der Gläubiger seinen Betrieb mit anfänglichen Einschränkungen durchführt. Es werden in jedem Fall echte Betreibungsdaten verwendet.


2 Best Practice für Gläubiger

2.1 Vor der Inbetriebnahme

2.1.1 Qualitätssicherung der eSchKG Software

Kontext Die Betriebsaufnahme von eSchKG setzt eine Reihe von qualitätssichernden Massnahmen voraus, einige davon werden durch den Standard vorgegeben. Zudem muss das Teilnehmerverzeichnis berücksichtigt werden.

IT / Prozesse Bevor eSchKG produktiv in Betrieb gehen kann, müssen Gläubiger die Testbed-Prüfungen durchführen. Danach folgen entweder a) Funktionstests mit Herstel-lern von Betreibungssoftware oder b) Qualitätssicherungs-Tests mit der Projekt-leitung eSchKG gemäss Teil III. (Qualitätssicherungs-Tests sind eine Dienstleistung des BJ. Das aktuelle Orange Book schreibt vor, dass Gläubiger mit den Herstellern von Betreibungssoftware zwingend tes-ten müssen. Diese Regel wird in der Folgeversion des Orange Books wegfallen).

Best Practice Als erstes sind alle vorgeschriebenen Prüfungen im Testbed gem. Testbed User Manual durchzuführen;

Danach Prüfungen mit Herstellern von Betreibungssoftware oder QA-Prüfung mit dem BJ;

Für Tests und Prüfungen ist das Bootstrap-Teilnehmerverzeichnis zu verwenden (in der Homepage verfügbar);

Rechtzeitig vor der Aktivierung (Termin laut Bereitschaftsmeldung) wird das Bundesamt für Justiz die aktuelle Version der Teilnehmerliste mit der SN Meldung versenden.

2.1.2 Bereitschaftsmeldung an das Bundesamt für Justiz BJ

Kontext Bevor der produktive Betrieb aufgenommen werden kann, müssen Gläubiger sich in das Teilnehmerverzeichnis aufnehmen lassen. Das geschieht mittels einer Bereitschaftsmeldung an das BJ.

IT / Prozesse Das BJ prüft, ob der Teilnehmer aktiv im Verbund teilnimmt und in der Lage ist, auf Meldungen aus dem Verbund zu reagieren. Vor dem vereinbarten Aufschalt-termin sendet das BJ daher eine SN-Meldung an den Gläubiger, welche dieser zur Kenntnis nehmen und dem Inhalt entsprechend reagieren muss.

Best Practice Bereitschaftsmeldung mittels Formular an das BJ einreichen (Formular ist als PDF-Datei in der eSchKG Homepage verfügbar);

Ab dem Datum, das in der Bereitschaftsmeldung unter "Für Abnahme-tests mit BJ bereit" eingegeben wurde, ist mit einer Meldung des BJ zu rechnen;

Die Meldung ist zu lesen, ein allfälliger Anhang zu öffnen und die darin enthaltenen Instruktionen oder Angaben zu befolgen;

Bei Erfolg wird das BJ den Teilnehmer für den gewünschten Aufschalt-termin aktivieren und das Teilnehmerverzeichnis entsprechend aktuali-sieren.


2.2 Einreichen von elektronischen Begehren

2.2.1 Einreichung nach Reorganisation (Zusammenlegung, Ämterfusion)

Kontext Wenn mehrere Ämter zu einem einzigen zusammengeschlossen werden, so wird das neue Amt in aller Regel seine bisherige Teilnehmer-ID behalten, wäh-rend die anderen, aufgelösten Ämter aus dem Teilnehmerverzeichnis gelöscht (eSchKG 2.0) resp. als inaktiv markiert werden (eSchKG 1.1a).

IT / Prozesse Nebst der Löschung aus dem eSchKG Teilnehmerverzeichnis werden inaktive Teilnehmer auch an die Sedex-Verwaltung gemeldet, sodass die Teilnehmer keine Meldungen mehr via Sedex versenden oder empfangen können.

Best Practice Damit allfällige Fusionen oder andere Änderungen in der Zusammensetzung des Verbundes rechtzeitig entdeckt und Probleme umgangen werden können, ist wie folgt vorzugehen:

Vor jedem Meldungsversand ist sicherzustellen, dass der Empfänger im Teilnehmerverzeichnis als "aktiv" geführt ist;

Ist ein vormals aktives Amt nach dem Verzeichnis-Update nicht mehr aufgeführt, so ist die Ursache wahrscheinlich eine Reorganisation resp. Zusammenlegung. Sind mit dem deaktivierten Amt Betreibungsfälle pendent, so ist die Zuständigkeit neu zu ermitteln. Der weitere Daten-austausch hat an das neu ermittelte Amt zu erfolgen;

Bei Versand von Meldungen an ein neues fusioniertes Amt sind die bis-herigen Identifikationsnummern beizubehalten, insbesondere credId,

repId und senderRefData;

Gläubiger sollten die bisherigen actorIdOffice-Nummern (Kunden-

nummer eines Schuldners im Amt) der an der Fusion beteiligten Ämter nicht weiter verwenden, sondern diese Nummern von Neuem "erlernen".

2.2.2 Signierte Dokumente eines Betreibungsamtes weiterverwenden

Kontext Gläubiger und Antragsteller für eine Betreibungsauskunft erhalten vom Betrei-bungsamt Meldungen mit signierten PDF-Beilagen.

IT / Prozesse Die Signatur identifiziert den Urheber der Unterschrift und stellt sicher, dass das Dokument seit der Signatur nicht verändert wurde. Ein digital signiertes Doku-ment, z.B. das Doppel des Zahlungsbefehls, kann jedoch nicht zwingend als Ersatz für das physische Original betrachtet werden. Jedoch erhöht eine gültige Signatur die Beweiskraft eines Dokuments erheblich. Die Betreibungsämter werden Begehren nicht mit der Begründung zurückwei-sen, dass die von einem anderen Amt produzierte und signiert Beilage ungenü-gend wäre.

Best Practice Signierte PDF-Beilagen sollten so abgelegt werden, wie sie empfangen wurden, es müssen keine Schlüssel- oder Zertifikate verwaltet werden, die Signatur wird auch nach Jahren noch geprüft werden können;

Signierte PDF-Beilagen eines Betreibungsamtes können im Rahmen der Fortsetzung oder Verwertung beim gleichen oder einem anderen Betrei-bungsamt genutzt werden.


2.2.3 Änderungen an den Gläubiger-Stammdaten und Auswirkung auf credId

Kontext Das Betreibungsamt ist verpflichtet, alle Angaben in den Begehren zu prüfen, so auch die Daten der Gläubiger und Vertreter. Diese bleiben normalerweise über längere Zeit unverändert. Das Amt kann die Begehren eines bestimmten Gläubigers effizienter verarbeiten, wenn es sich darauf verlassen kann, dass Adress- und Personendaten stabil bleiben, d.h. sie sind in aufeinanderfolgenden Begehren immer gleich. So kann sich das Amt einmal geprüfte Angaben des Gläubigers in späteren Begehren als validiert anerkennen.

IT / Prozesse credId ist die eindeutige und persistente Nummer des Gläubigers und wird von

der Stelle vergeben, die für den Betrieb des SEDEX-Anschlusses verantwortlich ist, ab welchem der Gläubiger seine eSchKG-Daten verschickt und empfängt. Im Normalfall ist das der Gläubiger selbst. Mit Hilfe von credId hat das Betrei-

bungsamt die Möglichkeit, Gläubigerdaten im eigenen System als wiederkeh-rende Stammdaten zu führen. (Andere Angaben, wie z.B. Zahlungsverbindung, müssen hingegen vom Amt in jedem Begehren neu überprüft werden.) Was über credId und den Gläubiger gesagt wurde, gilt sinngemäss für repId

und den Vertreter.

Best Practice Der Betreiber des Sedex-Anschlusses, meist der Gläubiger selbst, muss credId pro Gläubiger eindeutig und unverwechselbar vergeben;

Empfohlene Umsetzung: Aktualisiert der Gläubiger seine eigenen Anga-ben (Personalien oder Adresse), so soll das System nach dem Abspei-chern automatisch eine neue credId für diesen Gläubiger vergeben

und fortan nur noch diese verwenden;

credId darf nie wiederverwendet werden, nachdem sie einmal einem

Gläubiger zugewiesen worden war. Was über credId und den Gläubiger gesagt wurde, gilt sinngemäss für repId

und den Vertreter.

2.2.4 Verwendung von actorId

Kontext Bei jedem Begehren prüft das Betreibungsamt die Angaben zum Schuldner, wie Aufenthalts- oder Wohnort, Zivilstand usw. Wenn ein Gläubiger mehrere Betrei-bungen gegen den gleichen Schuldner vollziehen muss, dann ist es hilfreich und zeitsparend, wenn das Amt erkennen kann, um welche bereits früher geprüfte Person es sich handelt.

IT / Prozesse actorId ist vom Gläubiger im Begehren als Schuldner-Nummer mitzugeben.

Diese Nummer merkt sich das Betreibungsamt, sodass bei einer neuerlichen Betreibung gegen den gleichen Schuldner dessen Personalien als bereits ge-prüft erkannt werden. Damit wird das Verfahren beschleunigt.

Best Practice Der Gläubiger vergibt actorId für jeden Schuldner, den er betreibt und

behält diese Nummer in allen zukünftigen Begehren bei;

Am besten eignet sich dafür die Kundennummer;

Einmal vergeben darf actorId nicht für einen anderen Schuldner wie-

derverwendet werden;


2.2.5 Verwendung von actorIdOffice

Kontext Das Betreibungsamt weist jeder Person auf Schuldnerseite eine eindeutige Iden-tifikationsnummer zu: actorIdOffice.

IT / Prozesse Die Eindeutigkeit von actorIdOffice gilt nur für das betreffende Amt, sie ist

nicht amtsübergreifend. Zwei Betreibungsämter werden für den gleichen Schuldner höchstwahrscheinlich unterschiedliche Nummern verwenden, aber dafür gibt es keine Garantie. Gläubiger "lernen" actorIdOffice aus Nachrich-

ten des Amtes, z.B. in der SC Meldung.

Best Practice Die Kenntnisnahme resp. weitere Verwendung von actorIdOffice

durch den Gläubiger ist freiwillig, er darf sie ignorieren;

Der Gläubiger kann die Nummer in späteren Begehren als Teil der Schuldner-Angaben mitliefern, muss das aber nicht. Damit hilft er, das Verfahren zu beschleunigen. (Um dies zu ermöglichen, müsste er ein Verzeichnis führen, in welchem die actorIdOffice-Werte eines

Schuldners je Betreibungsamt ermittelbar sind.)

2.2.6 Verwendung von senderRefData

Kontext senderRefData ist die Referenznummer des Gläubigers für eine Betreibung.

IT / Prozesse senderRefData darf vom Gläubiger nur einmal festgelegt werden und muss

den Betreibungsfall eindeutig kennzeichnen. Die Eindeutigkeit gilt nicht nur für ein bestimmtes Amt, sondern generell. Des Weiteren gelten die verbindlichen Regeln betr. DECLARATION und REFERENCE im Blue Book.

Best Practice Der Gläubiger muss sicherstellen, dass senderRefData pro Betrei-

bung nur einmal vergeben wird;

Wird senderRefData in einem Betreibungsfall erstmals verwendet, so

weist das Betreibungsamt dem Fall diese Referenznummer für den wei-teren Meldungsaustausch zu;

Die erstmalige Verwendung von senderRefData durch den Gläubiger (sog. DECLARATION gemäss Blue Book) kann je nach Situation in der CR, CC oder RR Meldung erfolgen;

Alle anderen Meldungen verwenden senderRefData ausschliesslich,

um den Fall in der Datenbank des Betreibungsamtes aufzufinden (sog. REFERENCE gemäss Blue Book).

2.2.7 Verwendung von caseNumber

Kontext caseNumber ist die offizielle Betreibungsnummer.

IT / Prozesse caseNumber wird dem Gläubiger vom Amt mitgeteilt, z.B. in der SA Meldung

und in Meldungen, die eine Sequenz beenden.

Best Practice senderRefData bleibt die wichtigste Hauptreferenz.

Der Gläubiger soll in Meldungen und Begehren caseNumber nur dann verwen-

den, wenn der Fall nicht anders referenziert werden kann z.B. in einer Fortset-zung, deren Einleitung auf dem herkömmlichen Weg, d.h. nicht eSchKG, erfolgt ist.


2.2.8 Verwendung von caseDetails im Betreibungsbegehren (CR Meldung)

Kontext Der Gläubiger kann im Betreibungsbegehren die Besonderheiten einer Betrei-bung bekannt machen.

IT / Prozesse caseDetails/caseType zeigt besondere Eigenschaften eines Falles an:

ordinary: Normale Betreibung.

special: Eine Betreibung mit speziellen Umständen, z.B. weil sie auf einer

besonderen rechtlichen Grundlage beruht, z.B. Verlustschein. Da-mit wird dem Amt angezeigt, dass ggf. besondere gesetzliche Be-stimmungen zur Anwendung kommen, wie Fristen usw.

Best Practice Für spezielle Betreibungen sollte caseDetails/caseType auf special ge-

setzt werden.

2.2.9 Neuerliche Einreichung eines Betreibungsbegehrens nach gescheiterter Über-tragung

Kontext Die Einreichung eines Begehrens kann aus folgenden Gründen scheitern: a) Das Begehren ist beim Amt nicht angekommen, z.B. aufgrund eines

technischen Übertragungsproblems bei Sedex; b) Das Begehren ist angekommen, wurde aber vom Amt ignoriert. Der

wahrscheinlichste Grund dafür ist, dass der Gläubiger im Teilnehmer-verzeichnis nicht aktiviert ist (das Amt muss die Meldung ignorieren);

c) Das Begehren ist angekommen, aber technisch mangelhaft, z.B. weil es das XML-Schema des eSchKG Standards verletzt;

d) Das Begehren ist angekommen, technisch einwandfrei, das Amt weist es aus fachlichen Gründen zurück, z.B. Fortsetzungsbegehren ohne Rechtsöffnung.

IT / Prozesse Die Fälle a und b bedeuten, dass das Amt keine Kenntnis von irgendwelchen Falldaten hat, weil diese nie ins System gelangt sind. Ein klarer Hinweis dafür ist, dass der Gläubiger keine SA Meldung erhält. Für ein Begehren, bei dem senderRefData als DECLARATION eingesetzt

wird (vgl. Blue Book), gilt theoretisch, dass ein neuerlicher Versuch es einzurei-chen, mit den exakt gleichen Daten geschehen kann, insbesondere mit gleich-lautender senderRefData.

Best Practice Um Probleme von Anfang an zu vermeiden, sollte senderRefData nach ge-

scheiterter Übertragung bei einem erneuten Versuch neu vergeben werden.

2.2.10 Verwendung von collocation (CR oder CC Meldung)

Kontext Es kann hilfreich sein, dem Amt mitzuteilen, dass eine Forderung privilegiert ist.

IT / Prozesse Das Betreibungsamt prüft die Kollokationsklasse in jedem Fall.

Best Practice collocation nur angeben, wenn der Gläubiger signalisieren will, dass die

Forderung privilegiert sei. Ansonsten weglassen.


2.2.11 Neuerliche Einreichung eines Betreibungsbegehrens (CR Meldung) nach expli-ziter Rückweisung durch das Amt

Kontext Die Einreichung eines Begehrens kann aus folgenden Gründen scheitern: a) Das Begehren ist beim Amt nicht angekommen, z.B. aufgrund eines

technischen Übertragungsproblems bei Sedex; b) Das Begehren ist angekommen, wurde aber vom Amt ignoriert. Der

wahrscheinlichste Grund dafür ist, dass der Gläubiger im Teilnehmer-verzeichnis nicht aktiviert ist (das Amt muss die Meldung ignorieren);

c) Das Begehren ist angekommen, aber technisch mangelhaft, z.B. weil es das XML-Schema des eSchKG Standards verletzt;

d) Das Begehren ist angekommen, technisch einwandfrei, das Amt weist es aus fachlichen Gründen zurück, z.B. Fortsetzungsbegehren ohne Rechtsöffnung.

IT / Prozesse Die Fälle c und d bedeuten, dass das Amt die Falldaten ins System eingelesen hat und danach einen ausdrücklichen Entscheid gefällt hat, das Begehren zu-rückzuweisen. Das Amt hat den Fall registriert, insbesondere kennt es die sen-

derRefData des abgewiesenen Begehrens.

Best Practice Ein erneuter Versuch, das Begehren einzureichen, muss eine neue sender-

RefData enthalten.

2.2.12 Forderungen im Betreibungsbegehren (CR Meldung) eingeben

Kontext Seit Einführung von eSchKG 2.0 darf die Forderung insgesamt maximal zehn Einzelpositionen beinhalten.

IT / Prozesse Der Forderungsgrund (reason) wird unverändert in den Zahlungsbefehl über-

nommen. Das Betreibungsamt wird das Feld nicht für andere Zwecke interpretie-ren. Insbesondere darf es mit einem Gläubiger keine Mitteilungen oder Codes vereinbaren, damit Forderungen speziell verarbeitet werden sollen, z.B. um eine Liste von Einzelforderungen in einen der zehn Forderungsgründe "hineinzupa-cken". Es ist dem Betreibungsamt ausdrücklich untersagt, den Text einer Forde-rungsposition anders als wie angeliefert in den Zahlungsbefehl zu übernehmen.

Best Practice Keinen Versuch unternehmen, mehr als zehn Forderungspositionen an-zumelden (z.B. weitere Forderungen im Bemerkungsfeld eintragen);

Die erste Forderungsposition ist die Hauptforderung, die übrigen Positi-onen können für Nebenforderungen oder zusätzliche Hauptforderungen verwendet werden;

Soll eine Forderung mit mehr als 10 Positionen angemeldet werden, so kann in der Hauptforderung die Gesamtsumme der offenen Rechnungen und ein mittleres Zinsdatum angegeben werden (Umrechnung einzelner Zinsverfallstermine in ein einziges Zinsdatum). Die Hauptforderung kann wie folgt lauten: "Versicherungsvertrag Nr. 999. Offene Prämienrechnungen Nr. 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134 in der Zeit vom 1.1.2013 bis 30.09.2013." Oder: "Gesamte Ausstände gemäss folgender Auflistung: Rechnung 123: CHF 44.00 vom 12.02.2013 / Rechnung 124: CHF 44.00 vom 12.03.2013 / ..."


2.2.13 Zinsen auf Forderungen

Kontext Zinsen können in jeder Forderungsposition eingegeben werden. Sie zu erheben ist allerdings nicht in jedem Fall rechtmässig.

IT / Prozesse Pro Forderung ist nur eine Zinsangabe möglich. Wurden variable Zinsen verein-bart (z.B. Libor-abhängig), so müssen diese in einen mittleren Zinsfuss und ein mittleres Zinsdatum umgerechnet werden. Die Umrechnung ist Sache des Gläu-bigers, das Betreibungsamt wird keine derartigen Berechnungen vornehmen.

Best Practice Gläubiger sollten es unterlassen, unrechtmässige Zinsen zu erheben, da sie einen allfälligen Rechtsvorschlag begünstigen;

Unrechtmässige Zinsen sind namentlich: Zinsen auf bisher aufgelaufe-nen Zinsen, auf Mahnspesen, auf kumulierten bisherigen Kosten.

2.2.14 Fortsetzungsbegehren (CC Meldung) im Modus "original" einreichen

Kontext Im einfachsten Fall kann der Gläubiger die Fortsetzung durch einfache Willens-bekundung an das Betreibungsamt verlangen.

IT / Prozesse Häufig ist das Betreibungsamt, das die Betreibung eingeleitet hat, auch für die Fortsetzung zuständig. Falls kein Rechtsvorschlag vorliegt und allfällige Ab-schlagzahlungen diesem zur Kenntnis gebracht worden sind, so kann der Gläu-biger die Fortsetzung ohne weitere Umschweife verlangen. Auf eSchKG 2.0 bezogen bedeutet das, das Begehren mit CC/request/original einzurei-

chen. Der "Modus original" soll verwendet werden, falls a) … das zuständige Amt die Falldaten bereits kennt, egal ob mit oder oh-

ne eSchKG; b) … dem Amt alle Abschlagzahlungen des Schuldners mittels PN Mel-

dung vorgängig angezeigt worden sind; c) … es zwischenzeitlich keine Änderungen der Personen- oder Adressda-

ten des Gläubigers, Vertreters oder Schuldners gegeben hat;

Best Practice Verwenden Sie den Modus "original" wenn immer möglich.

2.2.15 Fortsetzungsbegehren (CC Meldung) im Modus "modified" einreichen

Kontext Falls seit der Einleitung Personen-, Adress- oder Forderungsdaten geändert haben, müssen diese Daten im Fortsetzungsbegehren präzisiert werden.

IT / Prozesse Der "Modus modified" ist zu verwenden, falls a) … die Forderungen nicht gleich lauten, wie im Betreibungsbegehren,

z.B. weil ein Teil-Rechtsvorschlag gutgeheissen wurde; b) … seit dem Betreibungsbegehren Personen- oder Adressdaten des

Gläubigers, Vertreters oder Schuldners geändert haben.

Best Practice Wenn sich seit der Einleitung weder Personen- noch Adressdaten und auch keine Forderungen geändert haben, verwenden Sie den Modus "original".


2.2.16 Fortsetzungsbegehren (CC Meldung) im Modus "novel" einreichen

Kontext Falls das Fortsetzungsbegehren die erste eSchKG Meldung für den entspre-chenden Fall ist, so sind alle Angaben zur Betreibung anzugeben.

IT / Prozesse Der "Modus novel" ist zu verwenden, falls a) … das Amt keine Kenntnis des Falles hat, weil die Einleitung von einem

anderen Amt behandelt wurde; b) … die Fortsetzung auf einem Verlustschein oder Pfandausfallschein be-

gründet ist, was automatisch zu einer neuen Betreibung führt (wenn auch im Stadium der Fortsetzung).

Wichtig: Im Modus "novel" ist senderRefData immer eine DECLARATION.

Best Practice Wenn seit der Einleitung Personen-, Adressdaten oder Forderungen ge-ändert haben und falls der Fall im Amt nicht schon mit eSchKG eingelei-tet worden war, verwenden Sie den Modus "novel";

andernfalls verwenden Sie den Modus "original", wenn möglich.

2.2.17 Mehrauslagen im Fortsetzungsbegehren anmelden

Kontext Bis er die Fortsetzung einreichen kann, hat der Gläubiger unter Umständen wei-tere Unkosten tragen müssen.

IT / Prozesse Mehrauslagen werden im XML-Feld CcExpenses deklariert.

Best Practice CcExpenses sind nur anzugeben, falls in der Zeit zwischen dem Erhalt des

Doppels des Zahlungsbefehls und der Fortsetzung besondere Auslagen angefal-len sind. Zu solchen besonderen Auslagen gehören namentlich

Gerichtskosten, z.B. für die Rechtsöffnung

2.2.18 Verwertungsbegehren (RR Meldung) einreichen

Kontext Um das Verwertungsbegehren zu stellen, reicht eine einfache Willensbekundung seitens des Gläubigers aus.

IT / Prozesse Die Verwertung erfolgt in jedem Fall im Betreibungsamt, das schon die Fortset-zung bearbeitet hat. Der Gläubiger kann ausdrücklich die Verwertung von be-stimmten gepfändeten Werten beantragen, entweder bewegliche Sachen oder Immobilien oder beides.

Best Practice Es reicht eine "leere" RR Meldungen, nur senderRefData;

Falls das Verwertungsbegehren die erste eSchKG Meldung an das Amt ist, ist senderRefData eine DECLARATION und die Betreibungsnum-

mer (caseNumber) ist zwingend anzugeben;

Bei Einkommenspfändungen wird kein Verwertungsbegehren benötigt.


2.2.19 Auskunftsbegehren stellen (DI Meldung)

Kontext Um einen Auszug aus dem Betreibungsregister über einen Dritten beantragen zu können, müssen Gläubiger einen Interessensnachweis erbringen, z.B. einen Vertrag, eine Absichtserklärung oder die Bewerbung für eine Mietwohnung.

IT / Prozesse Das Betreibungsamt prüft den Interessensnachweis. Ohne diesen wird keine Auskunft erteilt. Ausnahme: Behörden mit gesetzlichem Anrecht auf Einsicht in das Betreibungsregister müssen keinen Nachweis erbringen.

Best Practice Belege für den Interessensnachweis sollten generell in elektronischer Form vorliegen (PDF Format), damit sie als Anhang zur DI Meldung ver-schickt werden können;

Die Beleg-Dateien sind nicht elektronisch zu unterzeichnen. Eine ges-cannte Kopie in genügend hoher Auflösung (z.B. erkennbare Unter-schriften) ist ausreichend;

Die Belege sollten zeitnah mit dem Begehren (DI Meldung) an das Be-treibungsamt geschickt werden, vgl. Blue Book, Chapter 1;

2.3 Empfang/Lesen von Meldungen des Betreibungsamtes

2.3.1 Fachliche Antwort und Fehleranzeige in der SA Meldung

Kontext Die SA Meldung quittiert den Erhalt eines Begehrens und enthält Informationen darüber, ob das Begehren im Amt verarbeitet resp. akzeptiert wurde.

IT / Prozesse Falls das Begehren technisch fehlerhaft war und nicht bearbeitet werden konnte, enthält die SA Meldung das Element errors. In diesem Fall ist das Element

statusInfo/status auf 901 gesetzt (unbekannter Status).

Ein Begehren, das technisch in Ordnung ist, löst eine SA Meldung mit Element actionReport aus. actionStatus sagt aus, wie das Amt die Anfrage fach-

lich beurteilt:

done: Das Begehren / die Anfrage werden wie gewünscht bearbeitet;

rejected: Das Begehren / die Anfrage wurde aus fachlichen Gründen

zurückgewiesen.

Best Practice Das Vorhandensein des Elements errors ist bei Empfang der SA Mel-

dung automatisch zu erkennen und der Benutzer zu alarmieren;

Fachliche Rückweisungen sollten automatisch erkannt werden und der Benutzer ist zu alarmieren.

2.3.2 Anzahl zu erwartende Kopien des Doppels des Zahlungsbefehls

Kontext Je nach Lebenssituation des Schuldners wird der Zahlungsbefehl an mehrere Personen zugestellt, z.B. Ehefrau oder gesetzlicher Vertreter.

IT / Prozesse Das Betreibungsamt erzeugt pro Empfänger des Zahlungsbefehls eine separate SC Nachricht. Diese enthält das Doppel des Zahlungsbefehls als elektronische Kopie im Anhang. Das Element SC/numIssued nennt die Gesamtzahl der Zah-

lungsbefehle. Dies ist zugleich die Anzahl SC Meldungen, die abzuwarten ist, bevor weitere Schritte unternommen werden (Grund: jeder Empfänger des Zah-lungsbefehls kann Rechtsvorschlag erheben und so die Betreibung blockieren).

Best Practice Der Gläubiger soll keine weiteren Schritte, namentlich eine Fortsetzung der Betreibung, unternehmen, bevor nicht die letzte SC Meldung erhalten wurde.


2.3.3 Anzahl zu erwartende Kopien der Konkursandrohung

Kontext Je nach Lebenssituation des Schuldners wird die Konkursandrohung an mehre-re Personen zugestellt, z.B. Ehefrau oder gesetzlicher Vertreter.

IT / Prozesse Das Betreibungsamt erzeugt pro Empfänger der Konkursandrohung eine sepa-rate SP Nachricht. Diese enthält die Konkursandrohung als elektronische Kopie im Anhang. Das Attribut SP/outcome/bankruptcywarning/@numIssued

enthält jeweils die Gesamtzahl der Konkursandrohungen. Dies ist zugleich die Anzahl der SP Meldungen, die der Gläubiger erhalten wird.

Best Practice Der Gläubiger kann die Gesamtzahl der ausgestellten Konkursandrohungen berücksichtigen, muss das aber nicht.

2.3.4 Kostenangaben in Abschlussmeldungen

Kontext Nach Beendigung des Einleitungs-, Fortsetzungs- oder Verwertungsverfahrens meldet das Betreibungsamt die aufgelaufenen Kosten.

IT / Prozesse Das Betreibungsamt meldet das Total der offenen Kostenpositionen in der Betreibung mittels charges/@total.

Die Liste der Kostenpositionen ist gemäss dem Datenmodell optional, d.h. nicht alle Betreibungsämter werden diese Positionen melden.

Best Practice Die Kostenangaben sind keine Rechnungen und sollen nicht zur Auslö-sung von Zahlungsanweisungen verwendet werden. In jedem Fall ist die Rechnung des Betreibungsamtes abzuwarten;

Die Angabe unter charges/@total bedeutet: Die Gesamtheit aller of-

fenen Kosten im Betreibungsverfahren, ungeachtet der Sequenz;

Falls es mehr als eine Abschlussmeldung gibt (bei SC und SP möglich), so kann es zu unterschiedlichen Kostenangaben kommen, z.B. weil die Zustellung des zweiten Zahlungsbefehls Mehrkosten ausgelöst hat. Re-levant ist in diesem Fall die Kostenangabe in der zuletzt erhaltenen Ab-schlussmeldung.

2.3.5 Ergebnis der Fortsetzung verstehen

Kontext Je nach Situation des Schuldners führt das Fortsetzungsbegehren zur Pfändung oder Konkursandrohung. Was zu geschehen hat, entscheidet das Betreibungs-amt aufgrund von gesetzlichen Bestimmungen, z.B. Eintrag im Handelsregister.

IT / Prozesse Das Ergebnis der Fortsetzung wird in der SP Meldung wie folgt angezeigt.

SP/outcome/seizure zeigt eine Pfändung an.

SP/outcome/bankruptcywarning zeigt eine Konkursandrohung an.

Beides zugleich ist unmöglich.

Best Practice Der Gläubiger soll seine Prozesse so gestalten, dass er bei Erhalt der SP Mel-dung als erstes feststellt, ob das weitere Vorgehen in Richtung Verwertung oder Konkurs geht.


2.3.6 Ergebnis der Pfändung verstehen

Kontext Wenn es zur Pfändung kommt, so erhält der Gläubiger eine Pfändungsurkunde mit Angaben zu den gepfändeten Gegenständen oder einen Verlustschein (falls keine pfändbaren Güter vorhanden sind).

IT / Prozesse Konnte eine Pfändung vorgenommen werden, die den Forderungsbetrag vor-aussichtlich abdeckt, so wird eine Pfändungsurkunde ausgestellt (im Modell als deed bezeichnet).

Sind zu wenig pfändbare Gegenstände vorhanden und ist auch kein Einkommen pfändbar, so stellt das Betreibungsamt einen Verlustschein nach Art. 115 SchKG aus (im Modell als loss bezeichnet).

Best Practice Konnte gepfändet werden, so sind die Fristen für das Verwertungsbe-gehren zu berücksichtigen. Diese lauten je nach Art des gepfändeten Wertes (Sachen, Immobilien, Einkommen) anders. …/deed/seizureKind/gepfändeterWert/@deadlineFrom

( Verwertungsbegehren kann frühestens gestellt werden ab …) …/deed/seizureKind/gepfändeterWert/@deadlineFrom

( Verwertungsbegehren kann gestellt werden bis …)

Wurde ein Verlustschein ausgestellt, so zeigt das Element …/loss/lossKind an, wie damit weiter zu verfahren ist. rolling

heisst, der Verlustschein kann für eine neuerliche Fortsetzung innerhalb von 6 Monaten verwendet werden. standing heisst, dass mit diesem

Verlustschein ein neues Betreibungsbegehren gestellt werden muss.

2.3.7 RC Meldung empfangen

Kontext Nach Ablauf eines Jahres wird die Einkommenspfändung beendet und es kommt zum Verwertungsabschluss. Besteht weiterhin eine Restschuld, so stellt das Betreibungsamt einen Verlustschein nach Art. 149 SchKG aus.

IT / Prozesse Der Verwertungsphase und somit auch der Verwertungsabschluss werden mit der RR Sequenz modelliert.

Best Practice Der Gläubiger muss die Ankunft einer "standalone" RC Nachricht, z.B. als Folge einer Einkommenspfändung, jederzeit erwarten (vgl. CC und RR Sequenz im Blue Book).

2.4 Personen und Adressen

2.4.1 Gläubiger und Gläubigervertreter

Kontext In einer Betreibung kann sich der Gläubiger durch einen Dritten vertreten lassen. Dieser ist für die Abwicklung des Falles mit dem Betreibungsamt verantwortlich.

IT / Prozesse Gläubiger und Vertreter sind Akteure im eSchKG Modell.

Best Practice Gläubiger und Vertreter dürfen nicht identische Personen oder Firmen sein!


2.4.2 Wenn mehr als ein Gläubiger existiert

Kontext In der bisherigen Praxis ist es zu Betreibungen gekommen, in denen mehrere Gläubiger aufgeführt waren, die gemeinsame eine Steuerschuld eintreiben wol-len (Staatssteuer, Kirchensteuer etc.). Diese Praxis ist unzulässig.

IT / Prozesse Pro Betreibung kann es nur einen Gläubiger und einen Vertreter geben. Sind mehrere Anspruchsteller beteiligt, muss einer von ihnen oder ein Aussenstehen-der die Gruppe vertreten. Die Anspruchsteller können sich durch entsprechende Namensgebung als Gläubigergruppe erkennbar machen, z.B. "Gläubigerge-meinschaft der Steuerorgane Kreuzlingen".

Best Practice Sind mehrere Anspruchsteller an einer Betreibung beteiligt, muss die Gruppe als ein Gläubiger auftreten;

Die Betreibung ist durch einen Vertreter einzureichen, entweder einer der Anspruchsteller oder ein Aussenstehender;

Der Gruppe ist eine credId gemäss Blue Book zuzuweisen;

Ist der Vertreter ein Mitglied der Anspruchsteller, so ist diesem zusätz-lich eine separat Identifikation zuzuweisen, die in der Betreibung als Vertreternummer (repId) verwendet wird;

Die Ansprüche der einzelnen Mitglieder der Gruppe können nun als ei-genständige separate Forderungspositionen im Betreibungsbegehren aufgeführt werden.

2.4.3 Wenn mehr als ein Gläubigervertreter existiert

Kontext Es kommt vor, dass ein Gläubiger einer zentralen Inkassostelle angehört, die ihrerseits einen Vertreter für Betreibungssachen beauftragt. Zum Beispiel im Gesundheitswesen: Der Arzt ist Gläubiger, vertreten durch die Ärztekasse, wel-che ihrerseits ein Inkassobüro mit der Eintreibung von Ausständen beauftragt.

IT / Prozesse Eine Betreibung kennt einen Gläubiger und höchstens einen Vertreter.

Best Practice Liegt eine Kette von Gläubigervertretungen vor wie oben beschrieben, so gilt:

Gläubiger ist der ursprüngliche Leistungserbringer, der beim Schuldner ein Guthaben hat. In unserem Beispiel der Arzt;

Vertreter ist die Partei, welche die Geschäfte mit dem Betreibungsamt abwickelt. In unserem Beispiel das Inkassobüro;

Parteien innerhalb der Kette (hier: Ärztekasse) erscheinen nirgends.

2.4.4 Personenangaben richtig erfassen

Kontext Die person-Felder dienen der strukturierten Erfassung von Personendaten.

IT / Prozesse Die Felder sind von den erfassenden Stellen einheitlich zu beschreiben.

Best Practice person/gender: Die Angabe muss den Tatsachen entsprechen. Vor-

einstellungen (z.B. "U" für alle Personen) sind zu unterlassen;

person/lastName: Der eingetragene Nachname, z.B. "Meier" oder

"Meier-Müller";

person/lastNameAddon: Ein Namenszusatz zwecks eindeutiger

Identifizierung, z.B. der ledige Name. für Therese Meier (geb. Müller) bedeutet dies: lastNameAddon="Müller" (und lastName="Meier");

person/firstNames: Bei mehreren Vornamen sind diese mit einem

Leerschlag zu trennen, z.B. "Hans Rudolf". Zusammengesetzte Vorna-men sind als ein Name zu schreiben, falls dies der offiziellen Schreib-weise entspricht, z.B. "Hanspeter".


2.4.5 Adressangaben richtig erfassen

Kontext Die address-Felder dienen der strukturierten Erfassung von Adressdaten.

IT / Prozesse Die Felder sind von den erfassenden Stellen einheitlich zu beschreiben.

Best Practice address/street1 resp. address/street1: Zulässig sind Angaben,

die geeignet sind, eine umfangreiche Strassenadresse auf max. zwei Zeilen darzustellen, jedoch ohne Hausnummer;

address/buildingNo: Gebäudenummer oder Nummernbereich, z.B.

"30", "102-104";

address/poBox: Nur Postfachnummer, kein Postfachtext

o richtig: "123", o falsch: "Postfach 123", "Pf. 123", "Postfach";

address/zip: 4-stellige PLZ, wie sie auf einem Brief verwendet wird;

address/zipCode: 6-stellige PLZ der Post;

address/city: Ortsbezeichnung oder Gemeinde.

2.4.6 Schuldnervertreter und Mitbetriebene

Kontext Die Rolle eines Schuldnervertreters oder Mitbetriebenen wird vom Amt ermittelt und in den dafür vorgesehenen eSchKG-Meldungen an den Gläubiger gemeldet.

IT / Prozesse Die Rolle ist unter debtor/associates/associate/role abgelegt. Die

Bedeutung der Rollen lautet wie folgt.

spouse: Ehefrau, Ehegatte oder eingetragener Partner;

guardian: Gesetzliche Vertretung, z.B. Eltern von Minderjährigen oder

ein Beistand;

agent: Vertraglicher oder rechtlicher Vertreter (z.B. Anwalt);

organ: Gesellschafter einer betriebenen Unternehmung, der in seiner

Funktion als Betriebener adressiert werden kann, z.B. ein Verwaltungs-ratspräsident;

thirdparty: Person mit besonderem Status, z.B. Dritteigentümer. Die

Person fungiert in Betreibungsdokumenten häufig unter "Rechte Dritter".

Best Practice Gläubiger sollten sich über Beteiligte auf Seiten des Schuldners informieren, indem sie den Inhalt von role zur Kenntnis nehmen und ggf. entsprechende

Massnahmen ergreifen. Zum Beispiel kann es bei einem Schuldner mit gesetzli-cher Vertretung sinnvoll sein, nach einer Lösung mit dem Vertreter zu suchen, bevor die Betreibung fortgesetzt wird.

2.5 Beilagen (External Documents)

2.5.1 Elektronische Unterschrift für Beilagen

Kontext External Documents (Beilagen) sind Dateien im PDF Format, die mit den geeig-neten Mitteln elektronisch unterzeichnet werden können.

IT / Prozesse Beilagen im PDF Format können mittels einer Spezialfunktion des Message-Handlers vor dem Versand automatisch digital signiert werden, was ihren Ur-sprung sicherstellt und sie vor nachträglichen Veränderungen schützt.

Best Practice Gläubiger müssen Beilagen nicht signieren. Der Beweiswert ist nicht mit einer Urkunde resp. Verfügung des Betreibungsamtes zu vergleichen.


2.5.2 Titel des Dokuments richtig erfassen

Kontext Da die Beilage gemäss eSchKG-Namenskonvention vor dem Versand umbe-nannt werden muss, wird ihr ursprünglicher Titel resp. Dateiname mitgeliefert.

IT / Prozesse External Documents werden im Datenmodell wie folgt beschrieben.

Ursprünglicher Name des Dokuments (documentTitle);

Für den Transport verwendeter Dokumentname (canonicalName);

Format des Dokuments (mimetype).

Best Practice Im Feld documentTitle ist ein Titel oder der ursprüngliche Dateiname ohne

Angabe des Verzeichnispfades anzugeben.

richtig: "Statusbericht Puma", "Report", "pumaReport.pdf"

falsch: "C:\Projektdaten\Bericht", "./report.pdf",

"u:/usr/etc/puma/report.pdf"

2.5.3 Rechtzeitiger Versand von Dokumenten

Kontext External Documents (Beilagen) und die XML-Daten sind in unterschiedlichen Dateien enthalten. Sie "reisen" unabhängig voneinander zum Ziel.

IT / Prozesse Sollte die (in der Meldung deklarierte) Beilage während 24 Stunden nicht beim Betreibungsamt eintreffen, sendet dieses eine SA Meldung mit Fehler-Code 0206 ("Document not found").

Best Practice Die eSchKG Meldung (XML) und die Beilage (PDF) sollten zur gleichen Zeit an die MessageHandler OUTBOX ausgeliefert werden, damit sie von Sedex gleichzeitig verschickt werden;

Falls das Amt eine 0206-Fehlermeldung zurückschickt und das ur-sprüngliche Begehren senderRefData als DECLARATION verwendet

hatte, darf die neuerliche Nachsendung des Begehrens nicht mit der gleichen senderRefData erfolgen wie beim ersten Mal.

2.5.4 Format von Beilagen

Kontext Das Format von elektronischen Beilagen wird durch den eSchKG Standard ein-geschränkt.

IT / Prozesse Zugelassene Formate im eSchKG-Verbund sind PDF, PDF/A und CSV.

Best Practice Gläubiger dürfen nur PDF und PDF/A versenden;

Gläubiger müssen in der Lage sein, PDF, PDF/A und CSV zu empfan-gen (letzteres nur vom Absender BJ).


2.6 Zahlungseingänge melden

2.6.1 Zahlungen mit der PN Meldung anzeigen

Kontext Die PN Meldung dient dazu, das Betreibungsamt über Teilzahlungen des Schuldners zu informieren.

IT / Prozesse Wenn das Amt konsequent über alle Zahlungen informiert wird, so kann der Gläubiger das Fortsetzungsbegehren im Modus "original" einreichen mit der Folge, dass das Betreibungsamt die Forderungen von sich aus neu berechnet. Dadurch wird der Gläubiger entlastet und er hat erst noch die Gewissheit, dass die Betreibung inhaltlich einwandfrei fortgesetzt wird. Wird eine Fortsetzung im Modus "original" eingereicht, ohne dass alle Zahlungs-eingänge gemeldet worden sind, so trägt der Gläubiger die Folgen der Unterlas-sung.

Best Practice Eingehende Zahlungen des Schuldners sind dem Betreibungsamt un-verzüglich anzuzeigen, vorzugsweise mit der PN Meldung;

Es ist stets der volle Betrag des Zahlungseingangs zu melden, es sind keine Vorabzüge zu machen, z.B. für Spesen, etc.;

Die Rückmeldung des Amtes ist zu prüfen, um sicherzustellen, dass die Zahlung verrechnet wurde (SA Meldung, actionStatus ist "done").

2.6.2 Zahlungsmeldung vs. Betreibung bezahlt

Kontext Die PN Meldung dient dazu, das Betreibungsamt über Teilzahlungen des Schuldners zu informieren. Mit der SR Meldung kann der Gläubiger die Betreibung beenden. Die SR Mel-dung mit action="paid" führt zur sofortigen Beendigung der Betreibung, der

Status wird als "Bezahlt an Gläubiger" geführt und in einem späteren Auszug aus dem Betreibungsregister entsprechend angezeigt.

IT / Prozesse Wenn die Zahlungsmeldung (PN Meldung) dazu führt, dass die Restschuld prak-tisch Null wird, so kann das Betreibungsamt die Betreibung von sich aus been-den.

Best Practice Wenn der Gläubiger die Betreibung nach einem Zahlungseingang des Schuld-ners beenden will, weil die Zahlung die Restschuld deckt oder der Gläubiger eine allfällige Restschuld nicht weiter betreiben will, so soll er die Betreibung mittels SR Meldung (action="paid") beenden und keine PN Meldung senden.

2.7 Fallsteuerung und Statusabfrage (SR)

2.7.1 Statusabfrage

Kontext Der Gläubiger kann sich jederzeit elektronisch über den Stand eines Verfahrens informieren.

IT / Prozesse Die SR Meldung mit action="info" wird im Betreibungsamt automatisch mit der

SA Meldung beantwortet.

Best Practice action="info" nur verwenden, um den aktuellen Stand abzufragen;

Keine unnötigen Statusabfragen machen, nur weil man es kann. Insbe-sondere sollen keine routinemässigen SR Abfragen gemacht werden.


2.7.2 Betreibung beenden

Kontext action="paid" führt zur sofortigen Beendigung der Betreibung, der Status wird

als "Bezahlt an Gläubiger" geführt und in einem späteren Auszug aus dem Betreibungsregister entsprechend angezeigt.

IT / Prozesse Der Gläubiger kann die Betreibung jederzeit ohne Begründung beenden. "paid" bedeutet nicht zwingend, dass die Betreibung tatsächlich bezahlt worden ist, der Gläubiger will sie einfach beenden. Der Fall ist allerdings nur dann wirklich beendet, wenn die Aktion quittiert wurde, d.h. die SA Meldung enthält als Bestätigung action="paid" und actionSta-

tus="done". Einmal beendet, können danach keine Meldungen mehr für diesen

Fall an das Betreibungsamt gesendet werden.

Best Practice Soll die Betreibung nach einem Zahlungseingang des Schuldners been-den werden, weil eine allfällige Restschuld nicht weiter betreiben werden soll, so soll der Gläubiger die Betreibung mittels SR Meldung beenden und keine PN Meldung senden. Ansonsten bleibt der Fall im Betrei-bungsamt hängig;

Die Quittung (SA Meldung) ist stets zu überprüfen.

2.7.3 Letztmaliges Begehren rückgängig machen

Kontext Gläubiger können gewisse Schritte im Verfahren, die sie selber veranlasst ha-ben, wie z.B. ein Fortsetzungs- oder Verwertungsbegehren, rückgängig machen.

IT / Prozesse Mit action="stop" wird veranlasst, dass ein kurz zuvor eingereichtes Begehren

um Fortsetzung oder Verwertung zurückgezogen wird. In allen anderen Fällen ist "stop" wirkungslos und wird mit einer Rückweisung quittiert, d.h. SA Meldung mit actionStatus="rejected". Das gilt insbesondere für

Auskunftsbegehren (DI Meldung);

getätigte Zahlungsmeldungen;

Betreibungsbegehren (CR Meldung); "stop" kann vom Betreibungsamt nur dann erfolgreich befolgt werden, wenn es rechtzeitig eintrifft, d.h. wenn seit dem Begehren keine unwiderruflichen Schritte getätigt worden sind, wie z.B. eine Pfändung. Wurde "stop" erfolgreich angewandt, so wird das Amt den Stand der Betreibung so zurücksetzen, als wäre das letztmalige Begehren nie getätigt worden.

Best Practice "stop" eignet sich nicht zur Beendigung oder Aufhebung der Betreibung;

"stop" soll nur verwendet werden, um einen Irrtum oder ein übereiltes Begehren für die Fortsetzung oder Verwertung rückgängig zu machen.

2.7.4 Betreibung zurückziehen

Kontext Der Gläubiger kann eine Betreibung jederzeit zurückziehen. Der Rückzug unter-scheidet sich von der normalen Beendigung dadurch, dass die Betreibung in zukünftigen Auszügen aus dem Betreibungsregister nicht erscheint (Ausnahme: Behörden, denen zurückgezogene Betreibungen von Gesetzes wegen anzuzei-gen sind).

IT / Prozesse Mit action="undo" wird der Rückzug der Betreibung veranlasst. Der Fall wird beendet und der Status auf 801 Betreibung zurückgezogen gesetzt. Dieser Sta-tus ist nur von Behörden einsehbar.

Best Practice "undo" soll nur verwendet werden, wenn der Gläubiger ausdrücklich wünscht, dass die Betreibung fortan nicht im Betreibungsauszug ersichtlich sein soll.


2.8 Spezialmeldung

2.8.1 Empfangsbereitschaft für die SN Meldung

Kontext SN Meldungen erlauben die sichere und nachvollziehbare Übermittlung von Mitteilungen an andere Teilnehmer des Verbundes.

IT / Prozesse Jeder Teilnehmer des eSchKG Verbundes muss in der Lage sein, SN Nachrich-ten entgegen zu nehmen und zu verstehen.

Best Practice SN Meldungen des Bundesamtes für Justiz sind stets mit Priorität zu behandeln, d.h. sie müssen vor allen anderen Meldungen gelesen werden.

2.8.2 Eignung von Spezialmeldungen

Kontext Grundsätzlich können SN Meldungen an jeden Verbundteilnehmer verschickt werden, solange es sich um betreibungsrechtliche Informationen handelt.

IT / Prozesse Die SN Meldung ist geeignet, ein Begehren oder eine Anfrage auf elektroni-schem Weg an ein Amt zu richten. Eine solche Eingabe ist kein Ersatz für die strukturierte Eingabe mit eSchKG, ausserdem gilt sie nicht als Standardeingabe im Sinne der Verordnung und wird u.a. gebührentechnisch als Papiereingabe behandelt.

Best Practice Gläubiger müssen jederzeit eine SN Meldung eines Betreibungsamtes oder des Bundesamtes für Justiz erwarten;

SN Meldungen sind zweckgebunden, d.h. ausschliesslich für den Infor-mationsaustausch im Betreibungssachen einzusetzen;

SN Meldungen des Bundesamtes für Justiz haben immer höchste Priori-tät vor allen anderen Meldungen.

2.9 Elektronisches Teilnehmerverzeichnis

2.9.1 Amts-Identifikationsnummer

Kontext Betreibungsämter haben eine Identifikationsnummer gemäss Egeli und Schatz-mann.

IT / Prozesse Die Spalte EGE_ID dient dazu, ein Amt aufgrund seiner Identifikationsnummer von Egeli Informatik ausfindig zu machen. Die Spalte SMA_ID dient dazu, ein Amt aufgrund seiner Identifikationsnummer von Schatzmann Treuhand ausfindig zu machen.

Best Practice Ermitteln Sie zunächst die EGE_ID oder SMA_ID des zuständigen Am-tes, an das Sie ein Begehren senden wollen;

Die entsprechende Nummer kann danach im Teilnehmerverzeichnis als Schlüssel für die Suche nach der Sedex-ID des Amtes verwendet wer-den.


2.9.2 Typisierung der Teilnehmer

Kontext Jeder Verbundteilnehmer ist entsprechend seiner Rolle typisiert.

IT / Prozesse COL = Betreibungsamt COB = Betreibungs- und Konkursamt CRE = Gläubiger oder Anfragender für eine Betreibungsauskunft SRV = Aufsichtsbehörde TST = Testanschluss ferner: BAN (Konkursamt), PRV (ext. Datenlieferant), RCV (ext. Datenkonsu-ment)

Best Practice Senden Sie SchKG-Falldaten wie Begehren, Statusabfrage, Zahlungs-meldung etc. ausschliesslich an Teilnehmer vom Typ COL oder COB;

Versenden Sie keine produktiven Daten an Teilnehmer vom Typ TST;

Versenden Sie Testdaten ausschliesslich an Teilnehmer vom Typ TST.

2.9.3 Teilnehmerverzeichnis mittels SN Meldung empfangen

Kontext Wenn die Zusammensetzung des eSchKG Verbundes sich ändert, z.B. durch Neuzugänge, Ämterfusionen usw., so sendet das Bundesamt für Justiz das ak-tualisierte Teilnehmerverzeichnis mit der SN Meldung an die Verbundteilnehmer.

IT / Prozesse Die SN Meldung hat SnCode "eSchKG:updateMemberDirectory" und wird

vom Absender Bundesamt für Justiz im Format Text (.csv, Semikolon-getrennt)

verschickt. Es wird nur das Teilnehmerverzeichnis Version 2.0 versandt.

Best Practice Vor der Weiterverarbeitung ist sicherzustellen, dass der Absender der SN Meldung das Bundesamt für Justiz war (3-CH-19);

Das Teilnehmerverzeichnis ist für den Tag gültig, der im Dateinamen codiert ist;

Sind für einen bestimmten Stichtag mehr als ein Teilnehmerverzeichnis versendet worden, so ist dasjenige mit dem jüngsten Zeitstempel zu verwenden und die anderen zu ignorieren. Beispiel: eschkg_members_20140801T010000 ist zu verwenden und

eschkg_members_20140801T000000 zu verwerfen (weil älter);

SN Meldungen mit SnCode = eSchKG:updateMemberDirectory von

einem anderen Anschluss als jenem des Bundesamts für Justiz dürfen nicht befolgt werden. Sie sind dem Bundesamt für Justiz unverzüglich anzuzeigen.


3 Best Practice für Betreibungsämter

3.1 Entgegennahme von Daten

3.1.1 Gläubiger-Stammdaten und credId

Kontext Die Datenbank in der Betreibungssoftware eines Betreibungsamtes enthält nebst Falldaten auch solche über die beteiligten Parteien: Schuldner, Gläubiger, Vertreter etc. Diese werden oft in Form von Stammdaten gehalten, um jederzeit wiederverwendet werden zu können.

IT / Prozesse Grundsätzlich ist das Betreibungsamt verpflichtet, die Angaben in einem Begeh-ren zu übernehmen, es sei denn, das Amt habe mit hoher Wahrscheinlichkeit verlässlichere Informationen als die im Begehren angeführten, z.B. die Adresse eines Schuldners. Ansonsten sind die im Begehren gemeldeten Angaben in jedem Fall zu übernehmen. Da sich die Adressdaten des Gläubigers und Vertreters im Verlauf der Zeit kaum ändern, wurde ein Instrument geschaffen, um diese Angaben als Stammdaten pflegen zu können: Der Absender eines Begehrens ist verpflichtet, die Datensät-ze für Name und Adresse des Gläubigers und ggf. des Vertreters eindeutig zu kennzeichnen: credId und repId.

Best Practice Name und Adresse des Gläubigers und Vertreters sind grundsätzlich so zu verwenden, wie im Begehren angeliefert;

Beim erstmaligen Empfang von Gläubiger- oder Vertreterdaten MUSS das Betreibungsamt diese prüfen. Zugleich werden credId und repId

dem Amt vom Absender erstmals bekannt gemacht;

Einmal geprüft, SOLL das Betreibungsamt Gläubiger- oder Vertreterda-ten in die Stammdaten aufnehmen;

Beim Empfang von Begehren mit bekannten credId und repId gelten

die entsprechenden Gläubiger- und Vertreterangaben als validiert und müssen nicht jedesmal neu geprüft werden;

3.1.2 Zahlstelle des Gläubigers oder Vertreters

Kontext Zu den Gläubiger- und Vertreterangaben gehört u.a. die Zahlstelle.

IT / Prozesse Die Zahlstelle gehört nicht in die Stammdaten des Gläubigers oder Vertreters. Sie könnte theoretisch in jeder Betreibung anders lauten.

Best Practice Die Zahlstelle ist in jedem Fall so zu übernehmen, wie sie im Begehren des Gläubigers oder Vertreters eingereicht wird.

3.1.3 Angaben in Kommentaren

Kontext Der Gläubiger kann im Begehren einen Hinweis oder eine Bemerkung anfügen.

IT / Prozesse CR/caseDetails/remarks, CC/commentary, RR/commentary.

Best Practice Die Kommentare sind als Hinweise zu verstehen. Sie sind nicht in Betreibungs-urkunden, wie Zahlungsbefehl etc. zu übertragen.


3.1.4 Daten übernehmen wie eingereicht

Kontext Betreibungsdaten werden vom Gläubiger elektronisch angeliefert.

IT / Prozesse Die Daten sind hochstrukturiert. Namentlich kann die Forderung nur im Rahmen der Standardvorgaben eingereicht werden, d.h. max. 10 Positionen inkl. einer Limitierung der Länge des Forderungsgrundes.

Best Practice Das Betreibungsamt MUSS die Daten, insb. die Forderungspositionen, exakt so in den weiteren Prozess übernehmen, wie sie angeliefert worden sind.

3.2 Empfang von elektronischen Beilagen

3.2.1 Prüfung von Dokumenten des Gläubigers

Kontext Einem Begehren können Dokumente beigelegt sein, z.B. eine Vertragskopie als Interessensnachweis in einer Betreibungsauskunftsanfrage.

IT / Prozesse Gläubiger werden elektronische Dokumente, die sie dem Betreibungsamt beile-gen, nicht speziell für das Amt digital signieren (die Best Practices für Gläubiger raten davor explizit ab).

Best Practice Das Betreibungsamt SOLL beiliegenden Dokumente eines Gläubigers grund-sätzlich so behandeln, als wären sie in Papierform auf dem Postweg eingereicht worden (keine Diskriminierung von PDF-Anhangdokumenten). (Der Entscheid über die Berücksichtigung eines solchen Dokuments liegt nach wie vor allein beim Betreibungsamt.)

3.2.2 Anerkennen von Dokumenten anderer Ämter

Kontext Das Betreibungsamt liefert PDF-Dokumente als Beilagen zu den XML-Daten, namentlich für Zahlungsbefehl, Konkursandrohung und Betreibungsauskunft. Im Prinzip sind es Datenblätter, die im Kleid des offiziellen Formulars daherkommen und das Original grundsätzlich nicht ersetzen.

IT / Prozesse Folgende Tatsachen sind zu erwägen:

Die Anhänge (PDF-Dokumente) sind Formularkopien mit Falldaten, auf-bereitet gemäss den offiziellen SchKG Standardformularen;

Ein Anhang (PDF-Dokument) ist kein Scan des Originals, sondern wird von der Betreibungssoftware gesondert aufbereitet;

PDF-Dokumente werden von der Betreibungssoftware produziert, die ih-rerseits strengen Qualitätssicherungsmassnahmen durch das BJ unter-zogen worden ist;

Die PDF-Dokumente können nicht unerkannt gefälscht noch nachträg-lich verändert werden – der Empfänger kann die Echtheit und Integrität jederzeit überprüfen.

Best Practice Das Betreibungsamt SOLL Beilagen anderer Ämter, wenn sie im PDF Format vorliegen und vom Amt digital signiert sind, grundsätzlich so be-handeln wie eine Kopie oder ein Fax des Originals;

Das Fehlen von manuellen Notizen und Unterschriften ist normal und SOLL kein Grund darstellen, das Dokument nicht zu akzeptieren;

Das Betreibungsamt SOLL nach Möglichkeit auf die separate Zusen-dung eines Originals verzichten, wenn ein gleichwertiges PDF-Dokument als Anhang vorhanden ist.


3.2.3 Prüfung von digital signierten Dokumenten anderer Ämter

Kontext Jedes Betreibungsamt unterzeichnet PDF-Beilagen elektronisch. Die elektroni-sche Unterschrift identifiziert den Urheber und stellt sicher, dass das Dokument seit der Signatur nicht verändert wurde.

IT / Prozesse Eine digitale Signatur auf ihre Gültigkeit hin zu überprüfen ist ein komplexer Vor-gang, der normalerweise von einer eingebauten Verifikationsfunktion erledigt wird, z.B. im Adobe Reader.

Damit die Signatur verifiziert werden kann, muss Adobe Reader die Zertifikate resp. deren Herausgeber kennen. Weil dem Adobe Reader die Sedex-Zertifikate des eSchKG-Verbundes nicht bekannt sind, wird ein Warnhinweis angezeigt.

Die nötige Konfiguration des Readers, um eSchKG-Beilagen korrekt zu prüfen, kann umfangreich und komplex werden. Ausserdem wären sämtliche Reader bei allen potentiellen Empfängern von PDF-Beilagen entsprechend zu konfigurieren

Best Practice Bei Unsicherheiten betreffend der digitalen Signatur in einem Dokument kann der eSchKG-Signaturvalidator verwendet werden. Hinweis per 1.10.2014: Der Signaturvalidator ist in Arbeit.

3.3 Antwortmeldung SA

3.3.1 Fachliche Quittung

Kontext SA Meldungen sind fachliche Quittungen des Betreibungsamtes auf elektronisch eingereichte Anfragen oder Begehren.

IT / Prozesse SA Meldungen informieren darüber, ob ein Begehren vom Amt akzeptiert oder zurückgewiesen wird. Bei technischen Fehlern im elektronischen Begehren kann die SA Meldung eine Fehlerangabe enthalten (vgl. 3.3.3).

Best Practice Das Betreibungsamt SOLL die SA Meldung so rasch wie möglich erstellen und versenden. Konkret:

CR, CC, RR: Unmittelbar nachdem das Begehren geprüft und vom Amt zur weiteren Bearbeitung akzeptiert oder zurückgewiesen worden ist;

PN: Unmittelbar nachdem die Zahlungsmeldung geprüft und vom Amt akzeptiert oder zurückgewiesen worden ist;

SR: o Unmittelbar und automatisch bei action info,

o Unmittelbar nach Prüfung bei action paid, stop, undo.


3.3.2 Keine SA Meldung ausserhalb der Sequenz

Kontext SA Meldungen sind stets an eine eSchKG-Sequenz gebunden. Es gibt keine freien SA Meldungen.

IT / Prozesse -

Best Practice Sind nachträglich Dokumente oder andere Informationen an den Gläu-biger zu versenden, so soll die SN Meldung verwendet werden.

3.3.3 Fehlermeldung vs. Rückweisung

Kontext Das Betreibungsamt unterscheidet in seiner Antwort zwischen einer fachlichen Rückweisung und einem technischen Fehler.

IT / Prozesse Fehler sind nur dann zu melden, wenn mit dem elektronischen Begehren des Gläubigers oder Vertreters ein technisches Problem aufgetaucht ist.

Best Practice Fehler sind dann zu melden, wenn ein Grund gemäss Blue Book, Kap. 1.10 "Error Reporting and Exception Handling" vorliegt;

In allen Fällen, bei denen die Rückweisung fachliche Gründe hat, ist nicht ein Fehler, sondern SA/actionReport mit Inhalt rejected zu

melden.

3.3.4 Nicht reagieren

Kontext Das eSchKG-Teilnehmerverzeichnis enthält die Angaben aller im Verbund zuge-lassenen (aktivierten) Teilnehmer.

IT / Prozesse Meldungen von Sedex-Anschlüssen, die nicht im Teilnehmerverzeichnis enthal-ten sind, werden vom Betreibungsamt ignoriert.

Best Practice Es darf keine eSchKG-Meldung als Reaktion auf eine empfangene Mel-dung gesendet werden, wenn diese von einem nicht eingetragenen Mit-glied stammt;

Das gilt auch für SA mit Fehlermeldung. Selbst diese darf unter diesen Umständen nicht gesendet werden.

3.4 Versand von elektronischen Beilagen

3.4.1 Referenzierte Beilagen tatsächlich versenden

Kontext Elektronische Beilagen werden zusammen mit den XML-Daten versandt.

IT / Prozesse Das Element …/externalDocuments in den XML-Daten enthält pro Anhang

die folgenden Angaben: Ursprünglicher Name des Dokuments oder sein Titel, Dateiname, Format (MIME Type).

Best Practice Die Konsistenz zwischen den Angaben im XML und den tatsächlich versandten Dokumenten ist sicherzustellen, bevor XML und Anhang verschickt werden. Konsistenz heisst:

nur Dokumente schicken, die im XML referenziert sind,

was im XML als Dokument referenziert wird, muss tatsächlich gesendet werden.


3.5 Betreibungsauszug

3.5.1 Angaben zu Konkursen und Konkursverlustscheinen

Kontext Das offizielle Standard-Formular für den Betreibungsauszug sieht vor, dass nebst den Betreibungen und Verlustscheinen aus Pfändung auch Konkurse und Konkursverlustscheine gemeldet werden.

IT / Prozesse Nicht immer können Angaben über Konkurse und Konkursverlustscheine ge-macht werden.

Best Practice Das Betreibungsamt SOLL Konkurse und Konkursverlustscheine nur dann mel-den, wenn es über gesicherte Angaben verfügt, z.B. weil das Amt ein Betrei-bungs- und Konkursamt ist.

3.5.2 Zurückgezogene Betreibungen

Kontext Betreibungen, die vom Gläubiger zurückgezogen worden sind, werden im Betreibungsauszug nicht aufgeführt.

IT / Prozesse Es gibt Behörden, welche von Gesetzes wegen befugt sind, auch über die zu-rückgezogenen Betreibungen informiert zu werden. Diese Empfänger sehen die Betreibung unter der Statusangabe 801 (Betreibung zurückgezogen).

Best Practice Es liegt in der Verantwortung des Betreibungsamtes, diejenigen Stellen, welche Status 801 (Betreibung zurückgezogen) sehen dürfen, zu identifizieren und den Auszug entsprechend zu erstellen.

3.6 Kosten melden

Kontext Das Betreibungsamt meldet die Verfahrenskosten in den abschliessenden Mel-dungen der CR-, CC- und RR-Sequenz.

IT / Prozesse Das Attribut chargesType/@total enthält das Total aller offenen Kosten,

unabhängig von der Sequenz (d.h. es ist egal, in welcher Sequenz die Kosten gemeldet werden, sie betreffen stets die Betreibung als Ganzes).

Best Practice Das Betreibungsamt meldet das Total der noch offenen Kosten des Ver-fahrens im Attribut chargesType/@total. Diese Angabe gilt für den

Zeitpunkt der Meldung;

Einzelne Kostenpositionen können unter chargesType/details ge-

meldet werden (OPTIONAL);

Wenn einzelne Kostenpositionen gemeldet werden, so nur offene;

Folge: die einzelnen Kostenpositionen in chargesType/details er-

geben zusammen den Totalbetrag in chargesType/@total.


3.7 Barcodes auf Betreibungsurkunden

Kontext Die Schweizerische Post bietet Dienste an, um Dokumente auf ihrer Reise von und zum Betreibungsamt zu überwachen (Track-and-Trance). Dazu müssen die Dokumente an den entsprechenden Stellen mit Barcodes versehen werden.

IT / Prozesse Der eSchKG Standard schweigt sich über die Integration von Leistungen Dritter an der Logistik und dem Versand von Betreibungsurkunden aus. Die offiziellen Standardformulare Zahlungsbefehl, Konkursandrohung und Betreibungsauszug sind so spezifiziert, dass die entsprechenden Barcodes im Bedarfsfall ange-bracht werden können.

Best Practice Das Betreibungsamt ist für die Integration von Post-Dienstleistungen selber verantwortlich;

Das Betreibungsamt hat dafür zu sorgen, dass die Vorgaben zu den Standardformularen auch dann eingehalten werden, wenn Barcodes und Tags auf das Dokument aufgebracht werden.


Teil II

Fallbeispiele

(in Arbeit)


Teil III eSchKG Management Prozesse


4 eSchKG-Prozesse des Gläubigers

4.1 Prozesse gemäss Orange Book

Das Orange Book beschreibt den Weg zur Mitgliedschaft im eSchKG Verbund in sieben mo-dellhaften Prozessschritten.

1. Information 2. Make or Buy 3. Entwicklung 4. Anbindung 5. Testing 6. Bereitschaftsmeldung 7. Einführung

Die wichtigsten Vorgaben betreffen die Anbindung an den eSchKG Verbund (Schritt 4), die Konformitätsprüfung, genannt "Testing" (Schritt 5) und die Bereitschaftsmeldung (Schritt 6).

4.2 Bestellung eines Sedex Anschlusses für den eSchKG Verbund

Die Bestellung eines Sedex Anschlusses erfolgt über ein Webformular auf www.eschkg.ch.

Nachdem der Antrag durch das Bundesamt für Justiz geprüft worden ist, werden die benötig-ten Zugangsmittel auf einem Datenträger per Post zugesandt.

Nach der Installation der Sedex-Software ist der Teilnehmer grundsätzlich in der Lage, Nach-richten innerhalb der Sedex-Benutzergruppe "eSchKG" zu versenden und zu empfangen. Die Sedex-Benutzergruppe "eSchKG" entspricht dem Sedex-Meldungstyp 10301 und ist im Grunde ein VPN (virtual private network). Dabei hat Sedex keine Kenntnis vom Inhalt der übermittelten Daten und weiss z.B. nicht, ob es sich um eSchKG-Daten handelt.

Weil Sedex die inhaltliche Qualität der Daten nicht überprüfen kann, wurden Prüfverfahren und Konformitätstest definiert, die die Konformität von eSchKG-fähiger Software sicherstel-len. Wer diese Prüfungen besteht und damit die Korrektheit seiner Software nachweist, wird einer abstrakten Gruppe innerhalb der Sedex-Benutzergruppe "eSchKG" zugeordnet, dem sog. eSchKG-Verbund.

Hinweis: Indem man einen Sedex Anschluss erworben hat, ist man noch nicht Mitglied im eSchKG-Verbund. Mitglied wird man erst mit dem Eintrag im elektronischen Teilnehmerver-zeichnis durch das Bundesamt für Justiz.

Anmeldung für Sedex Anschluss

Sedex Meldungen für Typ=10301 senden/empfangen

eSchKG Software für Tests bereit

Eintrag im TN-Verzeichnis durch das BJ

eSchKG Teilnehmer-

Verzeichnis

Konformität der eSchKG SW ist nachgewiesen

Nicht Mitglied (im eSchKG Verbund) Mitglied


4.3 Prüfungen mit dem eSchKG Testbed

Die Prüfungen im eSchKG Testbed sind zwingend durchzuführen, bevor die Bereitschafts-meldung an das Bundesamt für Justiz ergehen kann.

Zu prüfen ist zunächst die Korrektheit der Datenformate von eSchKG-Meldungen im Upload-verfahren (sog. Formattest). Nach erfolgreichem Formattest folgen die sog. Integrationstest, bei denen die zu prüfende Software eSchKG-Meldungen via Sedex ans Testbed (7-4-1) schickt.

Die Tests mit dem eSchKG Testbed sind auf sämtliche Nachrichtentypen, die ein Gläubiger einsetzen will, anzuwenden.

Das Testbed User Manual zeigt detailliert auf, wie das Testbed für Format- und Integrations-

tests einzusetzen ist. Das Dokument steht in der eSchKG Homepage zur Verfügung.

4.4 Sanity Check

(in Arbeit)

4.5 QA Prüfung mit dem Bundesamt für Justiz

4.5.1 Was bedeutet QA Prüfung?

Die QA Prüfung ist ein Angebot des Bundeamtes für Justiz. Die Prüfung ist für Gläubiger freiwillig.

Es handelt sich um eine detaillierte Prüfung, die in dieser Form weder vom eSchKG Testbed noch durch die Sanity Check Prüfung abgedeckt wird und bei der Daten über den eSchKG Verbund ausgetauscht werden. Als Handlungsrahmen wird ein generisches Szenario heran-gezogen, das alle Betreibungsphasen umfasst. Der Gläubiger hat die Möglichkeit, an belie-bigen Stellen innerhalb dieses Szenarios anzudocken. Er kann mit der Einleitung beginnen, fortsetzen und verwerten. Er kann aber ebensogut bei der Fortsetzung oder bei der Verwer-tung beginnen.

SR, PN und SN Meldungen können zu jeder Zeit innerhalb des Szenarios abgesetzt werden.

Während der Tests hat der Gläubiger Einflussmöglichkeiten auf den Verlauf des Szenarios, z.B. kann er verlangen, dass eine Betreibung zu simulieren sei, bei der es Mitbetriebene gibt oder dass Fehler auftreten sollen, die vom Betreibungsamt entsprechend zu vermelden sind.

4.5.2 Rahmenbedingungen

Für die QA-Prüfung soll document/envelope/transactionInfo/usage nach Möglichkeit

production sein.

Der Test sollte insgesamt nicht mehr als 12 Betreibungen umfassen. Die Komplexität einer Betreibung kann mittels Szenario-Codes erhöht werden.

Einleitung Fortsetzung Verwertung

CR CC RR

SR, PN, SN SR, PN, SN SR, PN, SN


4.5.3 Steuerung mittels Szenario-Code

Der Gläubiger kann Inhalt und Ablauf der Betreibung beeinflussen, indem er in jeder Mel-

dung im Element document/envelope/sender/senderContact einen oder mehrere

Codes mitgibt. Damit der Code wirksam wird, darf die betreffende eSchKG Meldung selber keine Formfehler enthalten.

Der Code ist sprechend: er zeigt an, zu welcher eSchKG-Meldung die Steuerung gehört (z.B. CR01 für einen Code in der CR Meldung).

Codes in der CR Meldung

Code Anforderung des Gläubigers Antwort des Amtes kombinierbar mit

CR01 Bemerkungsfeld ist zu verwenden. SA/actionReport/remarks ist vorhanden.

CR04 … CR09

CR02 Einen Fehler melden. SA/errors/error 1 x vorhanden. n/a

CR03 Zwei Fehler melden. SA/errors/error 2 x vorhanden. n/a

CR04 Ehegatte wird auch betrieben, kein Rechtsvorschlag.

Es werden 2 SC Meldungen erstellt. CR01, CR09

CR05 Ehegatte wird auch betrieben, mit Rechtsvorschlag.

Es werden 2 SC Meldungen erstellt. Ehegatte erhebt Rechtsvorschlag.

CR01, CR09

CR06 Ehegatte und ein Beistand werden auch betrieben, kein Rechtsvorschlag.

Es werden 3 SC Meldungen erstellt. CR01, CR09

CR07 Ein Schuldner, keine Mitbetriebenen, Zahlungsbefehl ist nicht zustellbar.

SC/statusInfo/status = 103 CR01, CR09

CR08 Ein Schuldner, keine Mitbetriebenen. Der Betrag wurde zwischenzeitlich an das Amt bezahlt.

SC/statusInfo/status = 105 CR01, CR09

Die Spalte "kombinierbar mit" zeigt an, welche Codes zusammen in der gleichen Meldung aufgeführt werden können.

Versand durch Gläubiger

Meldung wird geprüft

ok?

Steuerungs-Code lesen

SA mit Feh-

lermeldung

yes no

Msg

Antwort gem. Code

Msg

Empfang durch Gläubiger

senderContact="CR01"


Codes in der CC Meldung


CC01 Es wird eine Sachpfändung vollzogen. SP/outcome/seizure/deed ist vor-

handen. Es gibt 3 Anhänge.

n/a

CC02 Es wird eine Einkommenspfändung vollzogen.

SP/outcome/seizure/deed vorhan-den. Es gibt 3 Anhänge. Es folgt eine "standalone" RC Meldung.

n/a

CC03 Die Pfändung führt zum Verlustschein nach Art 115.

SP/outcome/seizure/loss ist vor-

handen. Es gibt 2 Anhänge.

n/a

CC04 Es gibt eine Konkursandrohung. SP/outcome/bankrupctyWarning vorhanden.

n/a

CC05 Die Gläubiger-Referenz ist fehlerhaft SA mit Fehlermeldung, Fortsetzung wird nicht durchgeführt.

n/a

CC06 Die Betreibungsnummer ist fehlerhaft SA mit Fehlermeldung, Fortsetzung wird nicht durchgeführt.

n/a


Codes in der RR Meldung


RR01 Die Verwertung ist erfolgreich. RC/outcome/avails vorhanden.

Keine Anhänge.

n/a

RR02 Die Verwertung führt zu einem Verlust-schein nach Art. 149.

RC/outcome/loss vorhanden. Es gibt 1 Anhang.

n/a


Codes in der SN Meldung


SN01 SN mit 1 Anhang anfordern. SN mit Anhang wird geschickt. n/a

SN02 SN mit 1 Anhang anfordern (Gläubiger-referenz angeben, vgl. Beispiele)

SN für einen existierenden Fall mit Anhang wird geschickt.

n/a

SN03 SN mit 3 Anhängen anfordern. SN mit 3 Anhängen wird geschickt. Die Anhänge treffen verspätet ein

n/a

SN04 SN mit 3 Anhängen anfordern. SN mit 3 Anhängen wird geschickt. n/a

SN05 El. Teilnehmerverzeichnis anfordern. SN mit Verzeichnis wird geschickt. n/a


Beispiele

"CR01, CR05" In der SA Quittungsmeldung ist eine Bemerkung enthalten. Der Zahlungsbefehl

geht an den Schuldner und den Ehegatten. Der Ehegatte erhebt Rechtsvorschlag.

"CC02" Die Fortsetzung führt zur Einkommenspfändung.

"SN02, senderRefData=123" Der prüfende Gläubiger möchte eine SN Meldung empfangen, die

auf die Gläubigerreferenz 123 verweist und einen Anhang mitführt.


4.6 Bereitschaftsmeldung an das Bundesamt für Justiz

Das Formular Bereitschaftsmeldung kann von der eSchKG Homepage www.eschkg.ch her-

unter geladen werden (Home > Anmeldung).

Um die Bereitschaft für den eSchKG-Verbund melden zu können, müssen die folgenden Voraussetzungen erfüllt sein.

Für Anbieter von kommerzieller eSchKG-Software für Gläubiger:

1. ZWINGEND: Prüfungen im eSchKG Testbed sind durchgeführt worden; 2. Sobald verfügbar ZWINGEND: Sanity Check ist durchgeführt worden; 3. ZWINGEND: QA Prüfung mit dem BJ ist durchgeführt worden.

Für Gläubiger, die ihre eigene individuelle eSchKG-Software entwickeln:

1. ZWINGEND: Prüfungen im eSchKG Testbed sind durchgeführt worden; 2. Sobald verfügbar ZWINGEND: Sanity Check ist durchgeführt worden; 3. OPTIONAL: QA Prüfung mit dem BJ ist durchgeführt worden.

In der Bereitschaftsmeldung sind zwei Termine anzugeben:

1. Datum der gewünschten Aufschaltung für den eSchKG-Verbund (Zeitpunkt, ab dem der Gläubiger im 2.0-Teilnehmerverzeichnis erscheint);

2. Datum, ab welchem sowohl die Technik als auch die Organisation in der Lage sind, die Prüfmeldung (SN) des Bundesamtes für Justiz entgegen zu nehmen.

Das Timing ist wie folgt:

4.6.1 Abschliessende Verifikation durch das BJ

Das Bundesamt für Justiz wird eine letzte Verifikation durchführen, indem es dem Teilneh-mer eine SN Meldung zusendet, worin das BJ weitere Instruktionen gibt.

4.6.2 Empfangsbereitschaft für Meldungen des BJ

Die Meldungen des BJ müssen einen Teilnehmer auch dann erreichen können, wenn dieser noch nicht aktiviert worden ist. Auf der Gegenseite muss der Teilnehmer bereits vor der Auf-schaltung in der Lage sein, Daten von bestimmten Teilnehmern empfangen zu können. Dazu gehören alle Teilnehmer, die einen Anschluss für Testzwecke betreiben (Typ TST) sowie das Bundesamt für Justiz (Typ SVC). Um dies zu ermöglichen, wird das sog. Bootstrap-Verzeichnis benötigt, eine Version des Teilnehmerverzeichnisses, worin nur die Typen TST und SVC enthalten sind. Das Bootstrap-Verzeichnis steht in der eSchKG Homepage zum Download bereit (Navigation: Technische Hilfsmittel).

Bereit zum Empfang der Prüfnachricht SN

Zeit

Aktives Mitglied im eSchKG-Verbund

Bereitschaftsmeldung trifft im BJ ein

min 2 Wochen min 2 Wochen


5 eSchKG-Prozesse des Betreibungsamtes

5.1 Bereitschaftsmeldung an das Bundesamt für Justiz

5.1.1 Anmeldung durch den Softwarelieferanten

Betreibungsämter überlassen die Bereitschaftsmeldung dem Lieferanten der Betreibungs-software. Dieser kontaktiert das Bundesamt für Justiz und bestätigt, dass das Betreibungs-amt alle nötigen Voraussetzungen für die Teilnahme im eSchKG-Verbund erfüllt. Dies impli-ziert namentlich die Zusage, dass der eSchKG-Standard vollumfänglich eingehalten wird.

Der Lieferanten der Betreibungssoftware meldet mit der Bereitschaftsmeldung folgende An-gaben:

1. Name, Adresse und Sedex-Id des Betreibungsamtes; 2. Datum der gewünschten Aufschaltung für den eSchKG-Verbund (Zeitpunkt, ab dem

das Betreibungsamt im 2.0-Teilnehmerverzeichnis erscheint); 3. Datum, ab welchem sowohl die Technik als auch die Organisation in der Lage sind,

die Verifikationsmeldungen des Bundesamtes für Justiz entgegen zu nehmen.

Das Timing ist wie folgt:

5.1.2 Abschliessende Verifikation durch das BJ

Das Bundesamt für Justiz BJ wird eine letzte Verifikation durchführen, indem es dem Betrei-bungsamt eine SN Meldung zusendet, worin das BJ weitere Instruktionen gibt.

Das BJ kann für die Verifikation weitere Meldungen versenden, z.B. eine Abfrage der Statis-tikdaten (SI-Meldung) oder eine zweite SN Meldung.

Das BJ sorgt dafür, dass die Verifikationsprozedur den operativen Betrieb im Betreibungsamt nicht beeinträchtigt. Mit der Verifikation werden ausschliesslich Funktionen geprüft, welche die zukünftige Zusammenarbeit des Betreibungsamtes mit der Dienststelle Oberaufsicht betreffen.

5.1.3 Empfangsbereitschaft für Meldungen des BJ

Die Meldungen des BJ müssen vom Betreibungsamt auch dann empfangen werden, wenn dieser noch nicht aktiviert worden ist. Um dies zu ermöglichen, wird das sog. Bootstrap-Verzeichnis benötigt, eine Version des Teilnehmerverzeichnisses, worin nur Teilnehmer vom Typ TST und SVC enthalten sind und für den Rollout einer Betreibungssoftware geeignet ist. Das Bootstrap-Verzeichnis steht in der eSchKG Homepage zum Download bereit (Navigati-on: Technische Hilfsmittel).

Bereit zum Empfang der Verifikations-

Nachrichten des BJ

Zeit

Aktives Mitglied im eSchKG-Verbund

Bereitschaftsmeldung trifft im BJ ein

min 2 Wochen min 2 Wochen


5.2 Pflicht zur Entgegennahme von SN Meldungen

Das Betreibungsamt ist verpflichtet, eingehende SN Meldungen inkl. deren Anhänge zur Kenntnis zu nehmen.

SN Meldungen des Betreibungsamtes haben Vorrang vor jeder anderen Meldung und sind umgehend zu behandeln.

5.3 Versand von SN Meldungen

Das Betreibungsamt soll namentlich in den folgenden Fällen von der SN Meldung Gebrauch machen:

Zusendung von Informationen oder Dokumenten zu einem Betreibungsfall an einen Gläubiger ausserhalb der laufenden eSchKG-Sequenz;

Versand von Dokumenten an andere Betreibungsämter, z.B. im Rahmen der Amtshil-fe;

Die SN Meldung ist hingegen für die folgenden Situationen nicht geeignet:

Supportanfrage an das Bundesamt für Justiz;

Versand von Inhalten, die ausserhalb des Betreibungswesens liegen.

5.4 Teilnehmerverzeichnis einlesen

Das Bundesamt für Justiz kann das elektronische Teilnehmerverzeichnis für den eSchKG Verbund mittels der SN Nachricht jederzeit versenden. Das Verzeichnis ist ab einem be-stimmten Zeitpunkt gültig und muss daher rechtzeitig von der Betreibungssoftware eingele-sen werden. Abhängig vom Lieferant der Betreibungssoftware erfolgt das Einlesen automa-tisch oder unter Mitwirkung eines Mitarbeiters im Betreibungsamt.

In jedem Fall ist das Betreibungsamt für die rechtzeitige Verarbeitung einer Aktualisierungs-meldung für das Teilnehmerverzeichnis verantwortlich.

5.5 Statistikabfragen des Bundesamtes für Justiz

Das Bundesamt für Justiz kann jederzeit, voraussichtlich aber in regelmässigen Abständen, eine Statistikabfrage (SI-Meldung) an das Betreibungsamt senden. Abhängig vom Lieferant der Betreibungssoftware erfolgt die Bearbeitung der Anfrage automatisch oder unter Mitwir-kung eines Mitarbeiters im Betreibungsamt.

In jedem Fall ist das Betreibungsamt für die rechtzeitige Verarbeitung einer Statistikanfrage und für die Zusendung der Statistikdaten an das BJ verantwortlich.


6 eSchKG-Prozesse des BJ

6.1 Bereitschaftsmeldung eines Betreibungsamtes

Die Bereitschaft eines Betreibungsamts wird vom Betreibungssoftware-Lieferanten gemeldet. Die Bereitschaftsmeldung enthält die folgenden Angaben:

Name, Adresse und Sedex-Id des Betreibungsamtes;

Termin, ab welchem das BJ eSchKG-Nachrichten an das Amt versenden kann, um die Anmeldung zu verifizieren (vor dem Termin für die Aufschaltung);

Termin für die Aufschaltung.

Das BJ geht wie folgt vor:

1. Eingangsprüfung der Bereitschaftsmeldung; 2. Verifikation der Bereitschaft mittels eSchKG-Meldungen;

a. Sondermeldung, Anhang mit weiteren Instruktionen (SN) b. Statistikabfrage (SI)

3. Abwarten der Reaktion des Betreibungsamtes gemäss den Instruktionen sowie der Statistikdaten (SD);

Im Erfolgsfall:

4. Prüfung der eingereichten Unterlagen und Aktualisierung des Teilnehmerverzeichnis-ses in der Verbundmanagement-Applikation des BJ;

5. Publikation / Versand des Teilnehmerverzeichnisses, gültig ab dem Termin der Auf-schaltung des Betreibungsamtes (das Betreibungsamt wird nicht vor dem Aufschalt-termin im jeweils tagesaktuellen Verzeichnis erscheinen).

6.2 Bereitschaftsmeldung eines Gläubigers

Die Bereitschaftsmeldung eines Gläubigers enthält die folgenden Angaben:

Name, Adresse und Sedex-Id;

Bestätigungen über die erfolgreich durchgeführte Prüfung der Gläubiger-Software im eSchKG Testbed und Sanity Check;

Für Hersteller von kommerzieller Gläubiger-Software: Bestätigung für die erfolgreich durchgeführte Prüfung der Gläubiger-Software mittels Quality Assurance Tests;

Termin, ab welchem das BJ eSchKG-Nachrichten an den Gläubiger versenden kann, um die Anmeldung zu verifizieren (vor dem Termin für die Aufschaltung);

Termin für die Aufschaltung.

Das BJ geht wie folgt vor:

1. Eingangsprüfung der Bereitschaftsmeldung; 2. Verifikation der Bereitschaft mittels eSchKG-Meldungen Sondermeldung (SN), An-

hang mit weiteren Instruktionen; 3. Abwarten der Reaktion des Gläubigers gemäss den Instruktionen;

Im Erfolgsfall:

4. Prüfung der eingereichten Unterlagen und Aktualisierung des Teilnehmerverzeichnis-ses in der Verbundmanagement-Applikation des BJ;

5. Publikation / Versand des Teilnehmerverzeichnisses, gültig ab dem Termin der Auf-schaltung des Gläubigers (der Gläubiger wird nicht vor dem Aufschalttermin im je-weils tagesaktuellen Verzeichnis erscheinen).


6.3 Publikation des Teilnehmerverzeichnisses im Internet

Das Bundesamt für Justiz BJ verwaltet das eSchKG Teilnehmerverzeichnis und erstellt die entsprechenden Dateien für den Download für die Versionen 1.1a und 2.0 des Standards. Die Verzeichnisse werden täglich um 02:00 in der Homepage unter den folgenden URL ak-tualisiert:

Für eSchKG 1.1a:

Excel 97-2003: http://www.eschkg.ch/downloads/eSchKG_members.xls

Text (TAB-del.): http://www.eschkg.ch/downloads/eSchKG_members.txt

Für eSchKG 2.0:

Excel-2007-Format: http://www.eschkg.ch/downloads/2.0/xlsx

CSV (Text) Format: http://www.eschkg.ch/downloads/2.0/csv

Da es sich bei eSchKG 2.0 jeweils um das aktuelle Teilnehmerverzeichnis handelt, hat es unmittelbare Gültigkeit. Dies ist u.a. daran zu erkennen, dass der Zeitstempel im Dateinamen nie in der Zukunft liegt.

6.4 Versand des Teilnehmerverzeichnisses mittels SN

Für eSchKG 2.0 wird das Teilnehmerverzeichnis im CSV-Format via SN Meldung an alle Verbundteilnehmer geschickt. Das schliesst nebst den aktiven Teilnehmern auch solche ein, die kürzlich die Bereitschaft gemeldet haben und vom BJ verifiziert werden.

Der Versand erfolgt bei Bedarf, d.h. immer nur nachdem die Adressdatenbank der Verbund-teilnehmer aktualisiert worden ist. Der Versand wird manuell durch einen Mitarbeiter des BJ ausgelöst.

6.5 Ämterzusammenlegung / Fusion

Zusammenlegungen und Fusionen von Ämtern werden dem Bundesamt für Justiz durch die kantonalen Aufsichtsstellen gemeldet. Meldungen von Softwareherstellern oder von den Äm-tern selber werden vom BJ nicht berücksichtigt.

Der Zusammenschluss bedeutet, dass die beteiligten Ämter bis auf eines im Teilnehmerver-zeichnis als deaktiviert gekennzeichnet (Version 1.1a) oder gelöscht (Version 2.0) werden. Das verbleibende Amt übernimmt fortan die Geschäfte der übrigen Ämter. In der Regel erhält es eine neue Bezeichnung. Sobald das BJ Kenntnis von einer Zusammenlegung oder Fusion hat, passiert folgendes.

Für Inhaber eines physischen Sedex-Anschlusses:

1. Die für Sedex zuständige Stelle im BFS wird informiert, der neue Name des Amtes und die dazugehörige (existierende) Sedex-Id gemeldet;

2. Das BJ nimmt Kontakt mit dem neuen Amt auf und sorgt für ein Zeitfenster von 60 Minuten, in welchem der Sedex-Anschluss garantiert betriebsbereit sein muss;

3. Das BFS aktualisiert ihre Sedex-Teilnehmerdatenbank und ändert per Fernwartung die nötigen Bestandteile des Sedex-Anschlusses des Amtes, namentlich das elektro-nische Schlüsselmaterial inkl. Zertifikat, im vereinbarten Zeitfenster;

Für Inhaber eines logischen Sedex-Anschlusses:

1. Die für Sedex zuständige Stelle im BFS wird informiert, der neue Name des Amtes und die dazugehörige (existierende) Sedex-Id gemeldet. Ausserdem eine technische Kontaktperson für das Amt;

2. Das BFS aktualisiert ihre Sedex-Teilnehmerdatenbank;


3. Das BFS sendet das elektronische Schlüsselmaterial inkl. Zertifikat mittels FTP an den technischen Kontakt;

4. Das neue Passwort wird dem Amt per Post zugesandt; 5. Für die Installation, den Test und die Inbetriebnahme des neu aufgesetzten Sedex-

Anschlusses ist das Betreibungsamt verantwortlich.

Nach der Zusammenlegung ist das Sedex System auf dem aktuellen Stand und wird keine Nachrichten mehr an die vormaligen Sedex-Ids vermitteln. Wer es dennoch versucht, wird einen Fehler auf Sedex-Ebene gemeldet erhalten.

Laut der Gruppe der Lieferanten von Betreibungssoftware (Developers Group) ist sicherge-stellt, dass im fusionierten Amt

senderRefData (als REFERENCE) resp. caseNumber von bestehenden Fällen aus fusionierten Ämtern weiterhin verwendet werden können;

Alle bisher verwendeten Identifikationsnummern, insb. credId/repId, der GL-Kunden ihre Gültigkeit behalten.

6.6 Fusion von Gläubigern

(in Arbeit)

Sollte es zu einer Zusammenlegung oder Fusion von zwei Firmen kommen, die beide Teil-nehmer des eSchKG-Verbundes sind, so müssen laufende Fälle ohne Probleme weiter ab-gewickelt werden können.

Das BJ wird folgendes tun.

1. In Absprache mit der fusionierten Unternehmung wird einer der Sedex-Anschlüsse aufgehoben;

2. Das Teilnehmerverzeichnis wird entsprechend angepasst; 3. Die Betreibungsämter werden mittels einer SN Meldung über die Zusammenlegung

informiert.

Lizenzinformation Die Verwendung des eSchKG Standards ist freigestellt und kostenlos. Herausgeber Bundesamt für Justiz, Bundesrain 20, 3003 Bern, Schweiz Kontakt Fachbereich Rechtsinformatik Tel. +41 58 464 74 74 www.bj.admin.ch

[email protected]

eSchKG 2.0 Best Practice - sanitycheck.ch · eSchKG 2.0 Best Practice (Green Book) | Vorab-Version...

Documents

Transcript of eSchKG 2.0 Best Practice - sanitycheck.ch · eSchKG 2.0 Best Practice (Green Book) | Vorab-Version...