Reply: 40

SEPA für HR/HCM

Hallo zusammen,
ich habe mal eine Frage bezüglich der SEPA-Umsetzung in HCM. Für Gehaltszahlungen ist es erforderlich, den entsprechenden Textschlüssel in der DTA-Datei mitzugeben, damit der Gehaltseingang bei der Bank ersichtlich wird und keine Gebühren den Mitarbeitern in Rechnung gestellt werden.
Unter SEPA werden die Textschlüssel nun durch Purpose Codes abgelöst. Hierzu existiert seit kurzem der Hinweis 1630497, welcher das Thema adressiert.
Ich wunderte mich, dass im Standard kein Knoten ausgeliefert wird, eigentlich hätte ich dies erwartet, evtl. wäre dieser ausgeblendet oder mit NOTPROVIDED belegt gewesen. Deswegen war ich etwas verwundert, dass der Hinweis besagt, dass dieser Knoten zusätzlich zu definieren ist und im Prinzip eine Modifikation des SAP Standardbaums vorgenommen wird.
Dies wäre in meinen Augen wieder problematisch bei Update des Hinweises 1540040, da ich ja dann bei Aktualisierungen jedes Mal wieder diesen Knoten nachpflegen muss.
Hat sich von euch jemand schon mit HCM beschäftigt und hat evtl. einen besseren Lösungsweg?

You must be logged in to post a reply.

Login now

40 Answers

  • C.Schweitzer
    C.Schweitzer
    Hallo Sonic,
    also, nach meiner bisherigen Erfahrung ist der Knoten "PURP" im SPEA_DD standardmäßig vorgegeben. Die Sinnhaftigkeit ist mir bislang verborgen geblieben, weshalb man bei Lastschriften z.B. den Geschäftsvorfall SALA (Gehalt) angeben kann, bei Überweisungen jedoch nicht.
    Allerdings ist das Hinzufügen des Knotens im SEPA-CT kein großer Akt.
    Bzgl. Hinweis 1540040 empfiehlt es sich aber z.B. schon genau aus diesem Grund, nach dem Upload der anhängenden XML-Files den Formatbaum zu kopieren, um eben das Überspielen des Formatbaums bei Updates des Hinweises zu umgehen.
    Nach Rücksprache mit unserer Hausbank ist es übrigens keine Verpflichtung, Gehaltszahlungen kostenlos anzubieten. Unsere Hausbank z.B. sieht das in ihren Konditionen NICHT vor. Nichts desto trotz haben wir bislang immer den Knoten "PURP" manuell im SEPA_CT Baum hinterlegt.
    Viele Grüße
    C. Schweitzer
  • SonicNaitsabes
    SonicNaitsabes (Author)
    Hallo C. Schweitzer,
    die Sinnhaftigkeit blieb mir dabei leider auch verborgen, es ist in der Tat kein großer Akt, erzeugt aber bei jeder neuen Version Pflegeaufwand, da ich im Zweifel dem SAP-Baum vertraue, um nicht jeden Knoten einzeln zu prüfen, was sich verändert hat. Somit wäre ich immer gezwungen zu kopieren und wieder den PURP-Knoten zu ergänzen, finde ich halt nur umständlich und hätte aus meiner Sicht berücksichtigt werden können bei der SAP.
  • manug9
    manug9
    Hallo Zusammen,
    wie von euch schon besprochen gibt es im SEPA_DD-Baum den Knoten Purp, welchem die Konstante OTHR zugeordnet ist.
    Der von euch verlinkte Hinweis bringt mich nicht wirklich weiter, wie ich den Knoten Purp im SEPA_CT-Baum anlegen muss, vor allem
    im Hinblick darauf, wie ermittelt werden kann, ob es sich um eine Gehaltszahlung handelt oder nicht.
    Könnt ihr mir hierzu ein konkretes Beispiel geben?
    Danke,
    Manuel
  • C.Schweitzer
    C.Schweitzer
    Hallo Manuel,
    das ist kein Hexenwerk. Schau mal in die Anleitung. Ich habe das ganze bei uns am System mal nachgestellt. Nur komme ich derzeit nicht an den FuBa, der als Vorlage für den FuBa Z_SEPA_PURPOSE_CODE dient. Den müsste ich dann nächste Woche nachreichen.
    VG
    Carsten
  • manug9
    manug9
    Hallo Carsten,
    vielen Dank schonmal!
    Wäre super, wenn du den FUBA nachreichen könntest.
    Schönes Wochenende,
    Manuel
  • EC1055
    EC1055
    Hallo zusammen,
    als Vorlage für den Z-FuBa können die Bausteine DMEE_EXIT_TEMPLATE_ABA und DMEE_EXIT_TEMPLATE_EXTEND_ABA dienen (siehe F1-Hilfe am Feld "Exit-Funktion"). Diese enthalten allerdings kein Coding sondern definieren nur die Schnittstelle.
    Viele Grüße
    EC1055
  • jdoering
    jdoering
    Hallo Carsten, ich arbeite auch an dem Problem und wollte mir das Dokument ansehen (DMEE_Purp.dec). Leider kann ich es nicht öffnen. Kannst Du es nochmals zur Verfügung stellen?
    Viele Grüsse Jürgen
  • matthias.guenther
    matthias.guenther
    Hallo zusammen,
    ich habe auch eine Lösung. Ich nutze die Atome und . Die Lösung ist ausschließlich durch Customizing realisiert. Es muss kein Fuba angelegt werden! Die Lösung habe ich im angehängten PDF-Dokument festgehalten.
    Viele Grüße
    Matthias
  • EC1055
    EC1055
    Hallo Herr Günther,
    interessanter Ansatz. Danke, dass Sie Ihre Lösung hier zur Verfügung stellen. Für viele müsste diese Variante ausreichen.
    In der Lösung mit Funktionsbaustein, die ich einmal gesehen habe, wurde für 53000 zusätzlich noch über den Positionstext (FPAYP-SGTXT) zwischen Lohn/Gehalt ("SALA") und Rente ("PENS") unterschieden. Für diesen Fall stößt die Lösung ohne FuBa an Ihre Grenzen.
    Viele Grüße
    EC1055
  • matthias.guenther
    matthias.guenther
    Hallo EC1055,
    der Verwendungszweck (FPAYP-SGTXT) könnte auch über Customizing abgefragt werden. Zum Beispiel könnte auf einen fest wiederkehrenden String abgefragt werden ('Gehalt' 'Rente'). Jedoch würde ich bei wachsender Komplexität auch einen Fuba bevorzugen, welcher dann das Atom () befüllen würde. Für die meisten sollte jedoch meine Musterlösung ausreichen. Weiterführende Fragen einfach posten. Ich versuche Sie zu beantworten.
    Viele Grüße
    Matthias Günther
  • EC1055
    EC1055
    Hallo Herr Günther,
    da ich den Purpose Code nun selbst umsetzen darf und noch zwischen der reinen Customizing-/DMEE-Lösung und der FuBa-Lösung schwanke, noch eine Rückfrage: Warum haben Sie zusätzlich das Atom (Category Purpose) angelegt? In allen anderen Quellen, so auch im SAP Knowledge Base Article 1630497, wird immer nur das Atom gefüllt.
    Wofür wird die zusätzliche Angabe auf der PaymentInformation-Ebene benötigt? Kann man darauf ggf. verzichten?
    Viele Grüße
    EC1055
  • matthias.guenther
    matthias.guenther
    Hallo EC1055,
    den Hinweis 1630497 habe ich auch gründlich studiert und der ist aus meiner Sicht unvollständig. Ich habe vorletzte Woche die SAP Kurse WDDMEE und WDSEPA besucht. Dort erfuhr ich von einem anderen Teilnehmer vom Atom und von der Möglichkeit die Lösung nur mit Customizing zu realisieren. Zuvor wollte ich auch einen Fuba selber programmieren. Wieder im Büro habe ich die Lösung geprüft und erarbeitet. Ich habe mich dabei an einem Beispiel für eine Gehaltszahlungsdatei der HVB orientiert (siehe Anlage Seite 13). Jedoch ist das Atom dort falsch. Dort steht fälschlicher Weise . Aufgrund dieser zwei Informationen habe ich es mit aufgenommen. Einfach mal im SEPA Rulebook schauen. Dann habe ich einen Testdatenträger an die HVB (unsere Hausbank) geschickt. Das Ergebnis war ok.
    Kurz: Ich weiß nicht, ob es weggelassen werden kann. Jedoch schadet es nicht und kostet wenig Mühe es zu integrieren.
    Ich hoffe ich konnte weiterhelfen und stehe für etwaige Rückfragen bereit.
    Viele Grüße
    M. Günther
  • Maike
    Maike
    Hallo,
    seit 11.07.2013 ist der Hinweis 1885947 aktiv.
    Das scheint die Problematik zu beheben.
    Hat da schon jemand Erfahrungen mit gemacht?
    Grüße aus Bremen
    Maike
  • EC1055
    EC1055
    Hallo Maike,
    laut einem Beitrag im DSAG-Forum ist der Hinweis 1885947 noch unvollständig bzw. reicht allein nicht aus, um das Problem zu lösen.
    In dem Hinweis ist wohl nur der FI-Teil enthalten - das eigentliche Befüllen der REGUH im HR fehlt noch.
    Sonnige Grüße
    EC1055
  • Maike
    Maike
    Hallo EC1055,
    jetzt bin ich mal fies: Ist dafür nicht auch der Hinweis 1824522 relevant? Das ist der Hinweis der zum Teil erst ab Ende Juli/August 2013 (je nach Release) verfügbar ist. Der Hinweis sollte das Problem lösen, oder?
    Grüße aus Bremen
    Maike
  • EC1055
    EC1055
    Hallo Maike,
    der Hinweis 1824522 - HCM SEPA: ALE Verteilung der Infotypen 9 und 11 hat mit der Purpose Code-Problematik aus Hinweis 1885947 - SEPA Überweisungen: Integration mit HR nichts zu tun.
    Sonnige Grüße
    EC1055
  • Maike
    Maike
    Womit bewiesen wäre, dass ich keine Ahnung von HR habe.
    Also nur der Hinweis 1824522. Ok Danke.
    Grüße aus Bremen
    Maike
  • MB7331
    MB7331
    Hallo zusammen,
    beschäftige mich erst seit kurzem mit dem Thema SEPA und kämpfe aktuell mit der HR-Integration auf unserem System.
    Das Übernehmen der Positionstexte über den SAMPLE00 Verwendungszweck habe ich jetzt am Freitag bei meiner Internetrecherche rausgefunden, aber ich hänge noch an einem anderen Punkt:
    1885947 - Habe diesen Hinweis eingebaut, der Knoten taucht jetzt auch in der XML-Datei auf, aber wird nicht befüllt.
    Ich nehme an, dass mir ein Zwischenschritt fehlt im HR, dass der Code überhaupt befüllt ist, bevor es in der PMW darum geht alles in die XML zu schreiben.
    Hat jemand dieses Problem schon gehabt und kann mir einen Tipp geben?
    Danke und Grüße
    Matthias
  • EC1055
    EC1055
    Hallo Matthias,
    der Hinweis 1885947 deckt nur den FI-Teil ab, der HCM-Teil fehlt noch.
    Siehe auch die Aussage im Hinweis 1874075 - SEPA im HCM - Sammelhinweis: Purpose Code "Zur Zeit in Entwicklung".
    Viele Grüße
    EC1055
  • Mischorr
    Mischorr
    Hallo Zusammen,
    um den Knoten mit Inhalt zu füllen, ändert man in der DMEE bei diesem Element auf dem Reiter Attribute das Mappingverfahren auf Exit-Baustein und gibt dann auf dem Reiter Herkunft einen eigenen Exit-Baustein an. Ich habe dazu einen Funktionsbaustein mit der SE37 als Kopie des Bausteins DMEE_EXIT_TEMPLATE_ABA angelegt.
    Der FuBa liefert die Einzelzahlung in I_ITEM und darin in fpayp-xblnr den alten Code. Den habe ich mit einer Case-Anweisung auf den neuen Code umgesetzt und in c_value zurückgeliefert. Funktioniert bestens, auch wenn man den gleichen Baum im FI nutzt. Man muss nur sicherstellen, dass für alles Codes, die nicht HR betreffen, auch etwas zurückgegeben wird. Ich gebe dann OTHR als Purpose Code zurück.
    Bleibt nur die Frage, warum SAP nicht bereits beim Erzeugen der Zahlungen dafür sorgt, dass bereits die neuen Purpose Codes in xblnr stehen. Aber vielleicht kommt das ja noch ;-)
    Gruß aus Hamburg
    Matthias
  • Mr.SAP
    Mr.SAP
    Hallo Mischorr,
    wie genau hast du den Purpose Code "OTHR" im DMEE eingebaut? Ich habe bisher nur folgende Purpose Codes gefüllt: SALA,PENS (siehe Beispiel)!
    Müsste ich dann einfach nur eine dritte Zeile mit dem Wert "OTHR" einpflegen und dies dann auch im Fuba abfragen?
    Reicht dies dann eigentlich für eine HR-Zahlung aus oder muss noch seitens HR noch etwas eingestellt werden? Hast du damit Erfahrungen? Irgendwo habe ich gelesen, dass es noch einen Hinweis fürs HR_Modul von der SAP geben soll!
    Danke & Gruß
  • EC1055
    EC1055
    Hallo Mischorr,
    wie weiter oben ausführlich von Herrn Günther beschrieben, kommt man auch sehr gut ohne Funktionsbaustein aus.
    Unabhängig davon implementiert die SAP gerade eine Lösung für dieses Problem.
    Viele Grüße
    EC1055
  • S_K
    S_K
    Hallo,
    der Hinweis 1824522 beinhaltet doch aber keine Korrektur? Oder bin ich blind.....
    Danke!
    Gruß
    S_K
  • christian.wahner
    christian.wahner
    Hallo Zusammen,
    da es nicht sein darf das dieses Thema: SEPA-Purpose-Code in HCM von jedem individuell gelöst werden muss habe ich bei SAP nachgefragt. In den nächsten Tagen wird die SAP-Note 1900850 freigegeben. Im Kontext zur Note 1885947 sollte das das dann mit der
    Zuordnung der Purpose Codes funktionieren. Bin mal gespannt....
    Gruß Christian
  • ChrisB
    ChrisB
    Hallo Zusammen,
    naja, "nicht sein darf" ist meiner Meinung nach etwas hart formuliert
    Zumal die SAP im SAP-Hinweis # 1874075 folgendes schreibt: "Der HCM Teil soll voraussichtlich Ende September allgemein verfügbar sein" "In den nächsten Tagen" ist da wohl sehr weitreichend ausgelegt... Ende September hört sich für mich eher nach "in den nächsten Wochen" an!
    Und wir haben zwischenzeitlich September 2013 - zumindest bis vor kurzem hat SAP immer damit geworben, dass die SEPA Lösung 2008/2009 ausgeliefert wurde... naja, in Grundzügen sicherlich und irgendwie haben es wohl auch schon damals Kunden geschafft mit der Lösung live zu gehen
    Soweit ich das verstanden habe, ist für die empfangende Bank - sprich die Bank des Mitarbeiters und für die sendende Bank - sprich die Hausbank der Firma. Während bspw. dazu dienen kann, dass ein Gehaltskonto weiterhin kostenfrei ist, kann dafür sorgen, dass bspw. eine abweichende Valutierung für Gehaltszahlungen, durch die Hausbank, eingehalten werden. Ob das eine oder andere wirklich notwendig ist, das hängt wohl sehr stark von den individuellen Anforderungen der jeweiligen Banken und den jeweiligen individuellen Verträge zwischen den Banken und dem Mitarbeiter /der Firma ab!
    Viele Grüße
    Chris
  • christian.wahner
    christian.wahner
    Hallo Chris,
    da ich mit SAP arbeite erlaube ich mir nach 25 Jahren mit SAP auch mal ne Kritik.
    Deine Meinung respektiere ich natürlich aber an dieser Stelle im Zahlprogramm/REGHUH etc. ist SAP in der Pflicht im Standard eine Lösung anzubieten.
    In der Note 1874075 steht unter: "Zur Zeit in Entwicklung, Purpose Code: "...Hier benötigen sie zusätzlich Erweiterungen aus dem Bereich der Zahlungen (Hinweis 1885947, bereits freigegeben)..."
    Da der Hinweis 1885947 aber nur die halbe Lösung liefert ist die Nachfrage zu SAP gestellt worden und mit Hinweis 1900850 wohl dann gelöst.
    Gruß Christian
  • MDornburg
    MDornburg
    Liebe Forumsgmeinde,
    ich bin neu hier in diesem Forum und habe an Sie eine spezielle Frage zu unserem Problem.
    Wir haben in unserem SAP HCM mehrere Abrechungskreise mit XN Buchungskreisen.
    Zur Unterscheidung im Rahmen der DTA Erstellung haben wir bereits im Vorprogramm für jeden Abrechnungskreis eine eigene Variante mit einem eignen Identifikationsmerkmal zugeordnet. Das DTA Erstellungsprogramm SAPFPAYM hat ebenfall identische Varianten mit diesen Identfikationsmerkmalen.
    Da für eine Jobablaufplanung der SAPFPAYM_SCHEDULE benutzt werden soll, habe ich entsprechend pro Buchungskreis eigene Varianten mit eigenen Druckparametern in der OBPM4 angelegt.
    Dann habe ich eine Variante im Schedule mit dem zugehörigen Identfikationsmerkmal hinterlegt und einen Job laufen lassen.
    Erst mal sah alles gut aus, da pro Buchungskreis ein DTA mit entsprechenden Druckausputs prozessiert wurde.
    Dann habe ich für den nächsten Abrechnungskreis mit XN Buchungskreisen die Pflege der Varianten in der OBPM4 wiederholt und ein neue Variante des Schedule mit neuem Identifikationsmerkal angelegt und laufen lassen.
    Nun wurden zu diesem neuen Identifiaktionmerkmal alle bis dahin vorhandenen Varianten der OBPM4 durchlaufen und entsprechende doppelt DTAs erstellt.
    Nun meine Frage: Laut HW 1782685 soll über die Steuerung des Zeitpunkts 21 in der OBPM3 genau diese Problematik behoben werden. Hat dies schon jemand ausprobiert?
    Über Tipps würde ich mich sehr freuen.
    FG
    Monika Dornburg
  • weltbuerger
    weltbuerger
    MDornburg:

    Nun meine Frage: Laut HW 1782685 soll über die Steuerung des Zeitpunkts 21 in der OBPM3 genau diese Problematik behoben werden. Hat dies schon jemand ausprobiert?
    Über Tipps würde ich mich sehr freuen.
    FG
    Monika Dornburg

    Hallo zusammen,
    wir haben hier die gleiche Problematik. HR-Zahlungen sollen in ein anderes Schnittstellenverzeichnis für die Weiterverarbeitung im EBanking abgelegt werden, wie FI-Zahlungen. Grund hierfür ist die Weiterverarbeitung der HR-Zahlungen aus dem Schnittstellenverzeichnis. Alle Zahlungsdateien die von dort abgeholt werden, erhalten beim Import in das EBanking ein Vertraulichkeitskennzeichen und können daher von den zeichnungsberechtigten Kollegen nicht im Detail eingesehen werden. Auch die Drucksteuerung bezüglich der Begleitlisten ist hier je nach Herkunft und Buchungskreis unterschiedlich. Bei Zahlungsbegleitlisten macht es ggf. Sinn, diese für FI-Zahlungen automatisch zu drucken. Bei HR-Zahlungen wäre der Unternehmensfrieden gefährdet ;)
    Ich habe den Funktionsbaustein aus HW 1782685 von unserer IT anlegen lassen, nur wie gebe ich dem System die jeweiligen Parameter für die jeweiligen Läufe mit? Anwenderfreundlich ist was anderes.
    Die Problematik mit der unterschiedlichen Behandlung von FI und HR-Zahlungen müsste doch in vielen Unternehmen vorhanden sein. Daher wundere ich mich, dass dies über einen FuBa gelöst wurde.
    Gibt es da vielleicht noch einen anderen Lösungsansatz neben dem FuBa?
    LG
    Markus
  • Marco.K
    Marco.K
    Hallo zusammen,
    kennt jmd die Möglichkeit die DMEE für HCM so einzustellen, dass keine Einzelposten angezeigt / übertagen werden?
    Hintergrund:
    Wir wollten die SEPA HCM Zahlungen über SEPA_CT relaisieren - im Bankenprogramm sieht man jedoch die Einzelposten, demnach würde die MA die Rechte im Bankenprogramm haben die HR Zahlungen sehen.
    Besten Grüße
    Marco
  • christian.wahner
    christian.wahner
    Hallo,
    interessante Frage...
    Wir haben jetzt erfolgreich die erste Abrechnung/Zahlung Gehalt mit SEPA_CT durchgeführt.
    Wer macht denn bei Euch den Abrechnungslauf??
    Meinst Du mit Einzelposten das XML-File das man sich anzeigen lassen kann?
    Die erste Frage wie ist das mit euch arbeits-organisatorisch geregelt = Rollenverteilung???
    Gruß Christian
  • Marco.K
    Marco.K
    Hi,
    Super - hat alles funktioniert??
    Abrechnungslauf macht Personalverwaltung über SAP - HCM.
    Wir erstellen über SAPFPAYM und entsprechenden Varianten die XML Datei.
    Diese wird dann auf einen Fileserver gespeichert und vom Bankenprogramm (NewEBanking UC Prime von Hypo) eingelesen mit der Auftragsart CCT.
    Durch die Auftragsart kann jeder Mitarbeiter der im Bankenprogramm unterwegs ist, diese Zahlungen einzeln sehen - also jeden Mitarbeiter.
    Nun gibt es ja die Auftragsart XCT - Keine Einzelpostenanzeige. Die kann jedoch nur eine unserer Hausbanken...
    Die Auftragsart CCM ist veraltet und wird auch nicht von jeder unterstützt.
    Daher meine Frage ob ich in SAP schon eine Möglichkeit dies zu steuern, dass wie auch immer keine Einzelposten angezeigt werden.
    Von mir aus auch in der XML.
    Wichtig ist, dass im Bankenprogramm keine Einzelpostenansicht sichtbar sind - analog dem bekannten IZG Verfahren.
    Beste Grüße
  • christian.wahner
    christian.wahner
    Hallo Marco,
    "....auf einen Fileserver gespeichert..." das war der springende Punkt. Wir nutzen MultiCash und HR speichert ausschliesslich auf USB-Stick. Somit stellt sich das Problem bei uns so nicht. Da verschiedene Systemvoraussetzungen zwischen uns vorhanden sind kann ich weiter nix dazu sagen. Aber die Directories lassen sich doch bestimmt berechtigungstechnisch pflegen?
    Bei uns ist das HCM vollkommen separate SAP-Installation. Das Multicash ist auch so eingerichtet das die "normalen" F110ler MA's keinen Zugriff auf das Konto (ist auschliesslich Gehaltskonto) kommen.
    Gruß Christian
  • Marco.K
    Marco.K
    Hallo Christian,
    danke für deinen Hinweise.
    Wie kommt denn die Datei von USB Stick ins Bankenprogramm?
    Mit den Berechtigungen sind wir gerade dran...
    Ich habe nun von einer Bank das Stichwort - Batch Booking - bekommen.
    Kennt das jmd??
    Beste Grüße
  • christian.wahner
    christian.wahner
    Hallo Marco,
    die Daten vom USB-Stick kommen genauso wie von Festplatte, Netzlaufwerk via Windows-Upload-Dialogbox.
    "Ganz normal" bei MultiCash. Speicherung auf Fileserver kommt gar nicht in Frage, da immer nichtberechtigte Personen aus der Systemadministration (auch externe Mitarbeiter) die Daten sehen könnten.
    Gruß Christian
  • Marco.K
    Marco.K
    Moin Christian,
    an diese Lösung arbeiten wir auch gerade - Datei vom lokalen PC hochladen.
    Wir haben leider kein eigenes Gehaltskonto, daher können wir hier nicht mit Berechtigungen im Bankenprogramm arbeiten.
    Danke für die Tipps und beste Grüße
    Marco
  • MB7331
    MB7331
    Hallo Marco,
    ein Kunde bei dem ich nicht die SEPA Umstellung gemacht habe, hat mich auch schon mal darauf angesprochen. Es ging auch um SEPA Überweisungen aus dem HR-System.
    Ich habe mal in die technische Spezifikation der Hypo reingeschaut und dort folgendes gefunden:
    Unter dem Knoten kann man optional zwischen und den Knoten mitgeben.
    Dieser kennt nur die Werte "true" und "false". "true" wäre dann die Sammelbuchung.
    Auf die schnelle kann ich Ihnen leider nicht noch mehr Informationen geben, aber vielleicht hilft Ihnen das bei der Suche ja weiter.
    Grüße
    M
  • Marco.K
    Marco.K
    Hi,
    die Spezifikation der Hypo kenne ich auch schon :-)!
    Mal zur Info von mir:
    Die meisten Banken mit denen ich gesprochen habe, haben im Standard - Sammelposten als Kontoauszug zurückgeben - eingestellt.
    Möchte man nun Einzelposten im Kontoauszug haben, soll das Feld BatchBooking auf false gesetzte werden.
    Wird das Feld BatchBooking nicht mitgegeben, wird automatisch bei der Bank true gesetzt.
    Beste Grüße
    Marco
  • weltbuerger
    weltbuerger
    Marco.K:
    Hi,
    Super - hat alles funktioniert??
    Abrechnungslauf macht Personalverwaltung über SAP - HCM.
    Wir erstellen über SAPFPAYM und entsprechenden Varianten die XML Datei.
    Diese wird dann auf einen Fileserver gespeichert und vom Bankenprogramm (NewEBanking UC Prime von Hypo) eingelesen mit der Auftragsart CCT.
    Durch die Auftragsart kann jeder Mitarbeiter der im Bankenprogramm unterwegs ist, diese Zahlungen einzeln sehen - also jeden Mitarbeiter.
    Nun gibt es ja die Auftragsart XCT - Keine Einzelpostenanzeige. Die kann jedoch nur eine unserer Hausbanken...
    Die Auftragsart CCM ist veraltet und wird auch nicht von jeder unterstützt.
    Daher meine Frage ob ich in SAP schon eine Möglichkeit dies zu steuern, dass wie auch immer keine Einzelposten angezeigt werden.
    Von mir aus auch in der XML.
    Wichtig ist, dass im Bankenprogramm keine Einzelpostenansicht sichtbar sind - analog dem bekannten IZG Verfahren.
    Beste Grüße

    Moin Marco,
    1. Das Problem lässt sich nicht über die XML lösen.
    2. Die Lösung hierzu liefert euer UCprime eigentlich mit aus. Das Zauberrolle heisst hier "Vertrauliche Zahlungen" Diese Berechtigungsrolle kannst Du unter Admin-> Benutzerverwaltung den berechtigten Kollegen freischalten bzw. entziehen.
    2.1 Mit dieser Rolle ist es nun möglich in der Importschnittstelle für die SAP-SEPA-Dateien das Vertraulichkeitskennzeichen zu setzen. Ab dem Zeitpunkt können nur noch User, mit der Berechtigung die Zahlungsdetails beauskunften, alle anderen sehen zwar den Zahlungsauftrag und können diesen ggf. auch elektronisch unterschreiben, mehr aber auch nicht.
    2.2 Evtl. ist es sinnvoll, sich (Admin) nach Änderung der Schnittstelle diese Rolle wieder zu entziehen. Somit kann auch niemand an deinem Rechner Einblick in die Zahlungsdetails nehmen. Macht sich auch besser bei einer Prüfung über die Audit-Rolle ;)
    Bis hierhin ist eigentlich alles einfach, wäre da nicht SAP am Zahlungsverkehr beteiligt. Dein Problem wird jetzt sein, wie trenne ich Personalzahlungen deren Inhalt auf Teufel komm raus nicht bekannt werden darf, von Kreditoren+Debitorenzahlungen, bei denen der Detailinhalt zwingen einsehbar sein soll?
    3.1 Hier fehlen in der OBPM4 leider die Selektionsmöglichkeiten für die Zahlungsherkunft HR.
    Vorab, den Hinweis "1782685 - OBPM4: Unterschiedliche Varianten zu HR/HCM und FI, Bestimmung von Parametern im Exit " würde ich nicht umsetzen, der taugt aus meiner Sicht nicht die Bohne.
    3.2 Wir haben das so gelöst: Kred+Deb-Zahlungen werden über einen anderen Zahlweg (5) abgewickelt, wie Pers-Zahlungen (U). So haben wir in der OBPM4 dem Zahlungsformat SEPA_CT unterschiedliche Varianten mit unterschiedlichen Schnittstellenverzeichnissen, Druckern, Listenausgaben, etc. zuordnen. Wichtig wäre bei dieser Lösung, dass in den jeweiligen Varianten der richtige Zahlweg unter freie Selektion exklusiv zugeordnet wird. Je nach Zahlweg werden nun die SEPA-Zahlungsdateien von SAP in unterschiedliche Verzeichnisse auf dem Fileserver abgelegt.
    3.3 Das uc prime importiert diese Zahlungen nun je nach Importverzeichnis entweder mit Vertraulichkeitskennzeichen für HR-Zahlungen oder ohne für übrige SAP Zahlungen und stellt diese dann zur Unterschrift zu Verfügung und das mittels Auftragsart CCT (Egal ob HR, Kred, Deb, etc)
    Im Nachhinein eigentlich ganz simpel, wenn man mit zwei Zahlwegen und ohne Hinweis 1782685 leben kann.
    Ich hoffe, ich habe das nachvollziehbar beschreiben können. Habe gerade die Reinigungsfee mit aktivem Staubsauger im Büro...
    Muss nun auch los, wenn da was blöd beschrieben wurde, melde dich einfach noch mal.
    Gruss
    Markus
    EDIT sagt: Hab dir noch fix die Beschreibung aus der UC prime Hilfe angehängt.

    Zuletzt bearbeitet am 03.02.14 19:12

  • Marco.K
    Marco.K
    Hallo Markus,
    herzlichen Dank für Deine Infos!!
    Die vertraulichen Zahlungen kannten wir bis dato nur für manuelle Übergaben - sind gerade dabei dies mit automatischem Import zu testen!!
    Das sich der BankingAdmin selbst die Rolle wieder setzten kann, macht bei uns noch etwas Sorge, hier müssen wird definieren wie damit umzugehen ist...
    Das SAP Problem habe ich wie folgt gelöst:
    - Debi, Kredi Überweisungen haben den gleichen Zahlweg wie die HR Zahlungen.
    - SA38 - SAPFPAYM eigene Varaianten für HR erstellt, hier einen anderen Speicherpfad hinterlegt im Vergleich zu OPBM4 SEPA_CT Variante für Überweisungen Kredi, Debi
    - HR ruft dann den Download über FDTA auf und speichert die erstellten Daten in oben hinterlegten Pfad
    - UC Prime liest dann im Idealfall automatisch vertraulich ein.
    Ihr habt ja auch die XML Dateien auf einem Fileserver liegen. Hier sehen wir die Gefahr, dass sich jeder ADMIN zugriff auf den Ordner einstellen kann und somit die HR Zahlungen im Klartext sieht - XML ist ja nicht verschlüsselt.
    Gibt es hier eine Möglichkeit über das UCPrima zu verschlüsseln / direkt nach Import zu löschen??
    Grüße
    Marco
  • Marco.K
    Marco.K
    Hallo zusammen,
    eine kleine Neuigkeit:
    Unsere Hausbanken bieten nun mehr und mehr das XCT Verfahren an - hiermit kann ich eine CCT Datei (mit Einzelposten) via XCT Verfahren ins Bankenprogramm einlesen und sehe nur die Sammelposten!
    Beste Grüße
    Marco