18 Answers

• 00

  

  User #37178 12/6/13, 7:13 AM

  Hallo Hr. Plucinski,
  wir haben die End-to-End-ID bei uns wie folgt hinterlegt.
  Je nach Zahlungssystem (wir haben mehrere Zahlungssysteme im Haus für versicherungstechnische und nicht-versicherungstechnische Systeme) stellen wir zuerst die Systemkennung davor (fix vorbelegt), dann das Datum und schließlich das jeweilige eindeutige Ordnungselement, im Falle SAP das Feld FPAYH-DOC1R. Siehe Anhang
  mfg
  Wolfgang Neubauer

  report
• 00

  

  Plucinski (Author)12/6/13, 7:17 AM

  Hallo
  wo genau ist bei euch die Einstellung dazu in der dmee selbst ?
  Mit freundlichen Grüssen
  Jens Plucinski
  www.jensplucinski.de
  Beratender Betriebswirt SAP FI

  report
• 00

  

  User #37178 12/6/13, 7:34 AM

  Oh, ich bin kein Programmierer aber ich glaube schon. Anbei ein Screenshot

  report
• 00

  

  Plucinski (Author)12/6/13, 7:36 AM

  Yes, ich bin auch kein Programmierer, aber es sieht so aus, als nun der SAP Zahlungsbeleg reingeschrieben wird.
  Nochmals vielen Dank !
  Ticket kann geschlossen werden.
  Mit freundlichen Grüssen
  Jens Plucinski
  www.jensplucinski.de
  Beratender Betriebswirt SAP FI

  report
• 00

  

  fjott 12/10/13, 7:37 AM

  Hallo,
  in unserem Fall nutzen wir als Identifikation Debitorennummer und Zahlungsbeleg...
  Atombehandlung für EndToEndId dazu auf 02 gestellt.
  Neues Atom ZKUNNR an erste Stelle gesetzt, Füllung aus FPAYH-GPA1R
  Atom PAYD2 umfunktioniert: Länge 10 Zeichen mit Ziel-Offset 3, Herkunft: FPAYHX-OVBLN
  altes Atom "NOTPROVIDED" gelöscht
  funktioniert für unsere Zwecke hervorragend
  Wir benutzen noch DTI für Rückläufer und ich habe zunächst etwas sparsam geguckt, als nur noch "SVWZ+ RUECKLASTSCHRIFT" ankam und keine unserer im Verwendungszweck mitgegebenen Infos mehr zurückkam... EndToEndID wird hingegen über die EREF+ - Kennung zurückgeliefert!
  Edit: muss ich dazu sagen: wir füllen den Verwendungszweck über einen Exit, weshalb die Standardvorgaben (wo man auch den Typ 2 = E2E einstellen kann) nicht ziehen.
  Es ist auch möglich, im Exit über die Itab T_PAYMENT_DETAILS die E2E mitzugeben!
  

  Zuletzt bearbeitet am 10.12.13 15:04

  report
• 00

  

  silkekoerner 2/26/14, 1:46 PM

  Hallo zusammen,
  nachdem wir nun auch die Erfahrung gemacht haben, dass nach Umstellung auf SEPA_DD in der DTI-Rückläuferdatei gewisse Informationen fehlen, wollte ich so pfiffig sein, diese in der XML-Lastschriftdatei über die EndToEndId mitzuliefern.
  In unserem Fall sollen dort dieselben Informationen hinein, die wir bereits im Verwendungszweck (also analog Ustrd) darstellen. Klingt doch eigentlich einfach >> Einstellung per DMEE für PAYD2 analog REFERENCE1.
  Nun zeigt sich in erzeugten XML-Dateien folgendes Phänomen: Die Informationen erscheinen nur noch unter EndToEndId. Unter Ustrd fehlen sie; stattdessen wird "Not Provided" ausgegeben. Als sei die Verwendung NUR an dieser ODER an jener Stelle zulässig. Soll das so sein? Hat jemand eine Idee?
  Viele Grüße, Silke Körner

  report
• 00

  

  EC1055 2/27/14, 2:00 PM

  Hallo Frau Körner,
  im wird nur NOTPROVIDED ausgegeben, wenn alle 4 Zeilen des Verwendungszweck Typ 1 leer sind.
  Wenn Sie im Knoten etwas ausgeben möchten, muss lediglich der Verwendungszweck Typ 2 gefüllt werden (max. 35 Zeichen).
  Viele Grüße
  EC1055

  report
• 00

  

  silkekoerner 2/28/14, 11:11 AM

  Hallo und vielen Dank!
  Mit dem Verwendungszweck Typ2 hat es sofort funktioniert! Nun sind sowohl als auch korrekt gefüllt.
  Das ist schön
  Viele Grüße, Silke Körner

  report
• 00

  

  User #42811 8/20/14, 1:32 PM

  Hallo zusammen,
  besteht im Standard die Möglichkeit, die End to End Referenz (Verwendungszweck Typ 2) mit der Debitoren-Nummer zu füllen? Das würde ja auch hinsichtlich einer eventuellen Rückläuferverarbeitung (Zuordnung/ Reaktivierung des OP´s)) Sinn machen, da, wenn ich es richtig verstanden habe, diese Information auch wieder zurückgegeben wird. Ich kann dies über die F4 Hilfe aber nicht finden..
  Beste Grüße und vielen Dank vorab!!!!!

  report
• 00

  

  Center100 8/20/14, 7:37 PM

  Svengri:

  ---

  Hallo zusammen,
  besteht im Standard die Möglichkeit, die End to End Referenz (Verwendungszweck Typ 2) mit der Debitoren-Nummer zu füllen? Das würde ja auch hinsichtlich einer eventuellen Rückläuferverarbeitung (Zuordnung/ Reaktivierung des OP´s)) Sinn machen, da, wenn ich es richtig verstanden habe, diese Information auch wieder zurückgegeben wird. Ich kann dies über die F4 Hilfe aber nicht finden..
  Beste Grüße und vielen Dank vorab!!!!!
  

  
  Hallo Svengri,
  es gibt die Möglichkeit den Verwendungszweck sowohl über das Customizing einzustellen, aber dort kann auch ein Funktionsbaustein hinterlegt werden. Innerhalb dieses Funktionsbaustein kann der zuvor aufgebaute Verwendungszweck geändert bzw. Felder / Werte neu in den Verwendungszweck geschrieben werden. Dies ist dann absolut alles im Standard.
  Center100

  report
• 00

  

  Fjar 8/22/14, 6:59 AM

  Svengri:

  ---

  besteht im Standard die Möglichkeit, die End to End Referenz (Verwendungszweck Typ 2) mit der Debitoren-Nummer zu füllen? Das würde ja auch hinsichtlich einer eventuellen Rückläuferverarbeitung (Zuordnung/ Reaktivierung des OP´s)) Sinn machen, da, wenn ich es richtig verstanden habe, diese Information auch wieder zurückgegeben wird. Ich kann dies über die F4 Hilfe aber nicht finden..
  

  Es muß "nur" das richtige Tabellen- bzw Strukturfeld in der OBPM2 beim Verwendungszweck hinterlegt werden (Transaktion SE11 hilft beim suchen).
  Für die Kundennummer (die wir ebenfalls in der E2E-ID mitgeben) wäre das dann:
  Typ 2, Zeile 1, Ihre KtoNr. &FPAYH-GPA1R(Z)&
  Gruß
  Fjar

  report
• 00

  

  User #42811 8/22/14, 8:55 AM

  Hallo,
  erst mal vielen Dank für die Rückmeldung!!!
  @ Center100: da hast du Recht, hier war "Standard" der falsche Ausdruck...Verwendungszweck mittels Customizing meinte ich.
  @FJAR: &FPAYH-GPA1R(Z)& bezeichnet die Referenz zum Geschäftspartner, der die Zahlung erhält. Im Falle einer Lastschrift erhalte ich die Zahlung und möchte u.a. anhand der Debitoren-Nr. eine evtl. Rückläuferverarbeitung vereinfachen. Bei einer Überweisung mag für das Feld ja wahrsch. die KREDITOREN-ID gezogen werden...ich brauche aber die Debitoren-ID im Falle einer SEPA-Lastschrift... im Test (Customizing OBPM2: &FPAYH-GPA1R(Z)&)wird diese nicht gezogen....wenn ich mir anschaue wie viele Felder über Customizing auszuwählen sind ist für mich nicht nachvollziehbar weshalb dieses Feld über Customizing nicht gezogen werden kann...
  jemand eine Idee?
  Vielen Dank vorab!!!

  report
• 00

  

  Fjar 8/22/14, 9:15 AM

  Hallo Svengri,
  das ist sowohl bei SCT als auch bei SDD unsere E2E-ID, und im Datenträger erscheint bei uns auch die gewünschte Kreditoren- bzw Debitoren-Nr (wir arbeiten nicht mit Geschäftspartnern) - produktiv seit einem Jahr.
  Warum es dann bei Euch nicht funktioniert kann ich nicht beantworten.
  Gruß
  Fjar

  report
• 00

  

  EC1055 8/22/14, 9:30 AM

  Hallo Svengri,
  ich kann mich Fjar nur anschließen: FPAYH-GPA1R enthät bei Überweisungen den Kreditor und bei Lastschriften den Debitor. Die Bezeichnung des Feldes ("Geschäftspartner") ist irreführend. Deutlich wird dies auch über den Typ des "Geschäftspartners" in FPAYH-GPA1T. Hier sind u.a. möglich:
  Typ 01 = Zentraler Geschäftspartner
  Typ 11 = Lieferant, Kreditor
  Typ 12 = Kunde, Debitor
  Viele Grüße
  EC1055

  report
• 00

  

  User #42811 8/22/14, 10:55 AM

  Hallo,
  nochmal danke für eure Rückmeldungen.
  Ich habe mal ein wenig getestet und jetzt wird bei Lastschriften das Feld KUNNR tatsächlich gezogen...allerdings erst nachdem ich den Eintrag &FPAYH-DOC1R+4(10)&, also die Ausgleichsbelegnummer, die zusätzlich im internen VWZ stand, rausgenommen habe (obwohl die Länge des Feldes Interner VWZ mit 35 ausgesteuert ist...

  report
• 00

  

  Fjar 8/22/14, 11:26 AM

  Bei der Länge muß man sehr aufpassen. FPAYH-GPA1R ist bereits 16 Zeichen lang (maximale Feldlänge), macht bei 35 Zeichen maximaler Länge für die E2E-ID nur noch 19 Zeichen für sonstige Nutzung. FPAYH-DOC1R hat insgesamt 24 Zeichen Länge, somit passen die beiden Tabellenfelder nicht nebeneinander... Was auch der Grund ist, warum die DOC1R bei uns nur im Typ 4 steht ;)
  Gruß
  Fjar

  report
• 00

  

  User #42811 8/26/14, 12:59 PM

  Ja, man muss berücksichtigen, das unabhängig von der tatsächlichen Eingabe immer die maximale Länge des Feldes herangezogen wird.
  Ein Problem gibt es bei uns allerdings noch:
  Im Falle eines CPD-Kreditors zieht das System für das Feld FPAYH-GPA1R(Z) nicht mehr die Kreditoren-Nummer, was logisch ist. Stattdessen wird ein Teil des Namens mitgegeben. Für den Fall, dass dieser einen Umlaut enthält, bleibt die Datei mit Fehlermeldung hängen.
  Kennt jemand dieses Problem?
  Beste Grüße aus Aachen

  report
• 00

  

  Fjar 8/26/14, 1:10 PM

  Kann zwar nix zum CPD sagen, aber grundsätzlich muß der Zeichensatz sauber in der DMEE definiert sein.
  1. Entsprechenden SEPA-Baum aufrufen, und dann rechts unter Dateidaten die Definition der Zeichen gemäß dem jeweils anzuwendenen Rulebook pflegen. Achtung: EBICS Formatbeschreibung 2.6 und 2.7 haben unterschiedliche erlaubte Zeichen!
  2. Felder wie der Verwendungszweck müssen die unter 1. definierten Zeichen auch berücksichtigen. Hierzu muß das jeweilige Atom sauber befüllt werden. Unter Attribute gibt es das Feld "Konv.Fkt.", und dahinter ist ein Puzzlesymbol. Über dieses Symbol muß das Flag "Definierte Zeichen ausschließen/erlauben" aktiv sein, ansonsten werden die unter 1. definierten Zeichen nicht berücksichtigt und es kommen unerlaubte Sonderzeichen in den Datenträger. Das muß im Endeffekt bei sämtlichen fremdgefüllten Feldern (=keine Konstanten) im XML-Datenträger aktiviert sein, damit auch aus anderen Feldern (Name, Anschrift, Segmenttext etc) keine Fehler importiert werden.
  Gruß
  Fjar

  report