Bestimmte Funktionalitäten sind leider nicht verfügbar, da Ihr Browser das Javascript nicht berücksichtigt.
Zum Inhalt dieser Seite

Glossare - Allgemeine Informationen

Interpretieren der Anwesenheiten der Daten

Ein Glossar enthält 2 Arten von Karten, um die Angaben einer Meldung darzustellen:

  • Karten der Zonen
  • Karten der Blöcke

Für jede dieser Angaben - sowohl Blöcke als auch Zonen - wurde eine Anwesenheit definiert. Neben der Anwesenheit einer bestimmten Zone muss deshalb stets die Anwesenheit des Blocks, in dem die Zone erscheint, berücksichtigt werden.

Beispiel :

Der Block 90036 - Kommentar zur Meldung hat als Anwesenheit Fakultativ.

Das heißt, dass, falls gewünscht, alle Zonen in diesem Block angegeben werden können. In unserem Fall enthält der Block nur eine einzige Zone, nämlich 00126 - Zone mit freiem Text.

Die Zone 00126 - Zone mit freiem Text hat als Anwesenheit Unentbehrlich.

Das heißt, dass, wenn man den übergreifenden Block 90036 - Kommentar zur Meldung in die Meldung aufnehmen möchte, diese Zone obligatorisch anzugeben ist.

Wenn der Block besteht, gelten deshalb zusätzliche Bedingungen auf dem Niveau der Zonen.

Auf XML-Niveau ergibt dies:

Das XML-Tag des Blocks ist <CommentDeclaration>.

Das XML-Tag der betreffenden Zone ist <CommentOfDeclaration>.

Wenn kein Kommentar gewünscht wird, darf weder der Block noch die Zone vorhanden sein.

Folgendes ist deshalb NICHT möglich:

<CommentDeclaration></CommentDeclaration>

Wenn allerdings Kommentar gewünscht wird, müssen sowohl der Block als auch die Zone anwesend sein:

<CommentDeclaration>
  <CommentOfDeclaration>TEST</CommentOfDeclaration>
</CommentDeclaration>

Beschluss :

Die Anwesenheit auf dem Niveau einer Zone (siehe die Karte, die mit der Angabe im Glossar übereinstimmt), reicht nicht aus, um zu bestimmen, ob diese Angabe in der Meldung enthalten sein muss oder nicht.
Da die Zonen in Funktionsblöcken gruppiert werden, ist die Anwesenheit einer Zone der Anwesenheit des Blocks untergeordnet, zu dem die Zone gehört. Sogar dann, wenn eine Zone als unentbehrlich angegeben wird, kann es immer noch sein, dass sie nicht in der Meldung vorkommt, wenn der Block, zu dem sie gehört, fakultativ ist.
Die Karten in Bezug auf die Blöcke müssen deshalb auch abgefragt werden, (d.h. die „Anwesenheit“), um zu prüfen, ob eine Zone in Bezug auf eine bestimmte Angabe in der Meldung vorkommen muss.

Verwendung des TAGS <Location> (Zone 00295 - „Lokalisierung des Fehlers in der Baumstruktur“)

Mit diesem Tag können wir auf eindeutige Weise den Ort lokalisieren, an dem sich ein Fehler in einer hierarchischen Struktur, d.h. in einem XML-Dokument, ereignet hat. Deshalb kann jedes Element eines XML-Dokuments mithilfe eines „Pfads“ lokalisiert werden.

Da ein XML-Dokument eine hierarchische Struktur ist, kann sie mit einem Baum dargestellt werden. Außerdem können alle Elemente dieses Baums wie folgt nummeriert werden: Die Nummer, die einem Element zugeordnet wird, wird mit der jeweiligen Position (dem wie vielten Sohn) in Bezug auf das Vater-Element übereinstimmen. Wenn ein Element deshalb die Nummer n hat, handelt es sich um das Sohn-Element n des Vaters.

In der folgenden XML-Datei heißt dies:

<Wagen>
  <Innenseite>
    <AnzahlSitze>5</AnzahlSitze>
    <ElektrischeFenster>Avant<ElektrischeFenster>
  </Innenseite>
  <Außenseite>
    <AnzahlTüren>6</AnzahlTüren>
    <Metalliclackierung>OUIn<Metalliclackierung>
    <Länge>4,23</Länge>
  </Außenseite>
</Wagen>

Wenn wir davon ausgehen, dass die einzig zulässigen Werte für die Angabe <Metalliclackierung> die Werte „JA“ oder „NEIN“ sind, sehen wir, dass die Datei einen Fehler enthält. Diese Zone enthält nämlich „JAn“ als Wert.

Nachstehend finden Sie die Baumstruktur für dieses Dokument:

Baumstruktur XML-Schema Beispiel

Der Fehler in der Angabe „Metalliclackierung“ wird eindeutig wie folgt lokalisiert:

<Location>1,2,2,1</Location>

Allgemeine Hinweise zu ASR-Kontrollen

Die Verarbeitung der ASR, entweder über den Kanal Web (SP10) oder über den Kanal Batch (SP07), erfordert, abgesehen von den Diagrammkontrollen, eine Reihe von Kontrollen (Kreuzsicherungen' genannt). Diese Kreuzsicherungen integrieren im Grunde zwei Arten von Kontrollen:
  • Kreuzsicherungen im engsten Sinne (Formkontrollen, die zu kompliziert sind, als dass sie auf Ebene eines Diagramms durchgeführt werden könnten),
  • Inhaltskontrollen (durchgeführt unter Einsatz von Basisdiensten).
Beispiele einer Kreuzsicherung:
  • Prüfen, ob die Angabe 00045 (OccupationEndingDate) später oder gleichzeitig mit der Angabe 00044 (OccupationStartingDate) gemacht wurde.
  • Prüfen, ob, wenn die Angabe 00016 (System5) 1 entspricht, die Angabe 00047 (WorkingDaysSystem) gleich 500 entspricht.
  • Prüfen, ob die Angabe 00112 gemacht wurde, wenn die Angabe 00378 (EndYearBonusCode) gleich 3 ist ODER (die Angabe 00378 gleich 4 ist UND die Angaben 00387 (EndYearBonusAmount) UND 00111 (EndYearBonusValue) nicht ausgewiesen sind).

Beispiel der Inhaltskontrolle:

Sicherstellen, dass:

  • wenn sich das Datum des sozialen Risikos im laufenden Quartal befindet, die Angabe 00011 (NOSSRegistrationNbr) im Verzeichnis "Identifizierung des Arbeitgebers" vermerkt ist und das Datum des sozialen Risikos sich zwischen dem Eintragsdatum und dem Datum der Streichung dieses Registers in dem Verzeichnis befindet.
  • wenn sich das Datum des sozialen Risikos vor dem laufenden Quartal situiert, die Angabe 00011 (NOSSRegistrationNbr) vermerkt ist und sich im Verzeichnis "Codedatei" unter dem Datum des sozialen Risikos vermerkt ist.

Auf jeden Fall, wenn das Ergebnis einer Kontrolle inkorrekt ist, wird eine Fehlermeldung ausgelöst (die einen Fehlercode enthält, wie im Glossar dargestellt), die in der Notifikation erscheint, die dem überprüften ASR entspricht.
So ist zum Beispiel der Fehlercode, der sich auf das vorausgehende Inhaltskontrollbeispiel bezieht, 00011-051.
Zuletzt sei noch bemerkt, dass manche Kontrollen in mehreren Sektoren/Szenarien gleichzeitig durchgeführt werden, andere sind spezifisch.