Ansicht
Dokumentation

RPLGMBA0_STORNO - Stornierung ausgewählter Datenträger, mBGM-Pakete oder mBGMs

RPLGMBA0_STORNO - Stornierung ausgewählter Datenträger, mBGM-Pakete oder mBGMs

PERFORM Short Reference   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Verwendung

Mit diesem Report können Sie einen (fälschlicherweise übermittelten) Datenträger, ein mBGM-Paket oder eine mBGM beim SV-Träger stornieren, ohne im SAP-System weitere Stornos und Neumeldungen zu erzeugen.

Hinweis:Der Report RPLGMBA0_STORNO ist ein spezielles Korrekturwerkzeug. Er darf nichtregelmäßig in den mBGM-Prozess eingebunden werden. Der Report ist nur für Ausnahmefälle vorgesehen, in denen die Funktionen des Standardreports (RPLGMBA0) nicht ausreichen.

Voraussetzungen

Es existieren mehrere monatliche Beitragsgrundlagenmeldungen für die gleiche Personalnummer und Periode. Der SV-Träger kann nicht alle Meldungen verarbeiten. Eine Clearing-Meldung verlangt unter Umständen ein Storno (z.B. "Die Monatliche Beitragsgrundlagenmeldung wurde nicht verarbeitet, da für denselben Beitragszeitraum bereits eine Monatliche Beitragsgrundlagenmeldung gespeichert ist. Eine Stornomeldung ist erforderlich"). Mit dem Report RPLGMBA0 werden jedoch die nötigen Storno-Meldungen nicht erzeugt.

Das Paket, das storniert werden soll (bzw. die zu stornierende Meldung enthält) hat einen der der folgenden Statuswerte (srtza_echo_elda):

  • 410 (mBGM-Paket mit Warnung übernommen)
  • 411 (mBGM-Paket übernommen)

Funktionsumfang

Selektion

  • Datenträgernummer: Feld EDTNR aus der IST-Tabelle
    Dieser Wert ist obligatorisch. Sie müssen genau eine Datenträgernummer angeben.
  • Paketreferenzwert: Feld REFPO aus der IST-Tabelle
    Dieser Wert ist optional. Sie können mehrere Paketreferenzwerte angeben.
  • mBGM-Referenzwert: Feld REFNO aus der IST-Tabelle
    Referenznummer der mBGM, die storniert werden soll.
    Dieser Wert ist optional. Sie können mehrere mBGM-Referenzwerte angeben.
    Hinweis: Dies ist in der Regel nicht die mBGM, die den Clearingfall ausgelöst hat!

Wenn Sie weder Paketreferenzwerte noch mBGM-Referenzwerte angeben, wird der komplette Datenträger storniert!

  • Stornomodus: Art und Weise, wie das Storno in der Datenbank abgebildet wird.
  • Simulationsmodus: Es werden keine Daten im SAP-System geändert.

  • Einfaches Storno beim SV-Träger: Der Report erzeugt ein ELDA-File mit Stornosätzen, setzt aber die stornierten mBGMs im SAP-System auf Status 409 (mBGM-Paket nicht übernommen). Es werden keine Stornosätze in die SAP-Datenbank eingefügt.

  • Storno mit SAP-DB-Insert: Der Report erzeugt ein ELDA-File mit Stornosätzen und belässt die stornierten mBGMs im SAP-System auf Status 411 (mBGM-Paket übernommen). In den Tabellen T5A75_IST und/oder T5A76_IST werden neue Stornosätze eingefügt.
    Hinweis: Den Status für die neuen Stornosätze müssen Sie mit der regulären Statusrückmeldung auf den Status 411 (mBGM-Paket übernommen) setzen.

Standardvarianten

Ausgabe

Beispiel

Es wurden auf SAP-Seite mehrere mBGM-Pakete für die gleiche Personalnummer und Periode erzeugt, und es wurden falsche Statuswerte vergeben.

  • Paket Awurde zwar erzeugt, wurde aber entweder nicht abgeschickt wurde oder von ELDA nicht angenommen.
Paket A wurde fälschlicherweise mit dem Status 411 (mBGM-Paket übernommen) markiert.
  • Paket Bwurde per ELDA erfolgreich an die ÖGK versendet und auch dort verarbeitet.
Paket B wurde fälschlicherweise mit dem Status 409 (mBGM-Paket nicht übernommen) markiert.
  • Bevor die falschen Statusangaben im SAP-System korrigiert werden konnten, wurde bereits Paket Cerzeugt und an die ÖGK gesendet.
  • Paket C enthält ein Storno auf Paket A und eine Neumeldung. Paket C löst bei der ÖGK eine Clearingmeldung aus, da das zu stornierende Paket A bei der ÖGK unbekannt ist, aber eine Neumeldung ohne eine entsprechende Stornomeldung nicht möglich ist.
Der Report RPLGMBA0 erzeugt immer nur Stornomeldungen für Paket A, da dieses Paket im SAP-System mit dem Status 411 als gültiges Paket gekennzeichnet wurde. Bei der ÖGK bekannt ist dagegen nur das Paket B.

Aktivitäten

Um neue Stornomeldungen, Neumeldungen und weitere Clearingfälle zu verhindern, setzen Sie den Status wie folgt:

  • Alle Pakete, die nicht abgeschickt oder von ELDA nicht angenommen wurden: Status 409 (mBGM-Paket nicht übernommen).
    Im Beispiel oben: Paket A
  • Das Paket, das beim SV-Träger verarbeitet wurde und storniert werden soll: Status 411 (mBGM-Paket übernommen)
    Im Beispiel oben: Paket B
    Hinweis: Es dürfen nur solche Meldungen storniert werden, die bereits beim SV-Träger vorliegen.

Verwenden Sie den Report wie folgt, um die korrekte Stornomeldung für den aktuellen Clearingfall zu erzeugen:

  1. Geben Sie im Selektionsbild die Datenträgernummer des zu stornierenden Pakets an.
    Im Beispiel oben: Paket B.
  2. Falls erforderlich, schränken Sie die Treffermenge auf eine Paket-Referenznummer oder mBGM-Referenznummer weiter ein.
  3. Wählen Sie zunächst den Stornomodus Simulationsmodus.
  4. Starten Sie den Report und kontrollieren Sie die Ausgabe.
  5. Starten Sie den Report erneut, diesmal nicht im Simulationsmodus.
  6. Der Report erzeugt ein ELDA-File mit den Stornosätzen und aktualisiert die Tabellen T5A1O_ELDA, T5A1P und T5A1O_REF.
    Die Stornos beziehen sich nur auf mBGMs im spezifizierten Datenträger/Paket.
  7. Einfaches Storno beim SV-Träger
    Die stornierten mBGM-Sätze bekommen den Status 409 (mBGM-Paket nicht übernommen) und werden beim nächsten Soll-Ist-Vergleich nicht mehr berücksichtigt.
    Es werden keine Storno-Sätze in den Tabellen T5A75_IST und T5A76_IST eingefügt.

    Storno mit SAP-DB-Insert
    Es werden Storno-Sätze in den Tabellen T5A75_IST und/oder T5A76_IST eingefügt.
    Die stornierten mBGM-Sätze behalten den Status 411 (mBGM-Paket übernommen). Sie werden beim nächsten Soll-Ist-Vergleich nicht mehr berücksichtigt, sobald die neuen Storno-Sätze ebenfalls den Status 411 (mBGM-Paket übernommen) haben.
  8. Stellen Sie sicher (z.B. durch eine Rollung der Abrechnung in die betroffene Periode), dass für jede so stornierte mBGM eine gültige mBGM beim SV-Träger und im SAP-System synchron vorliegt.
    Im oben beschriebenen Beispiel liegt eine mBGM bereits vor (Paket C), da sie selbst Auslöser für den Clearingfall war.






General Data in Customer Master   Fill RESBD Structure from EBP Component Structure  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 8477 Date: 20240520 Time: 130650     sap01-206 ( 117 ms )