ToDo für Umstellung auf SEPA (nur Überweisungen, keine Lastschriften)

[klein_thomas]

Vorab:

• Wir tätigen nur Überweisungen, keine Lastschriften - SEPA ist also nicht so der Angstgegner hier
• unser Workflow zum Begleichung unserer Eingangsrechnungen ist folgender:
  • DTAUS-/DTAZV-Dateien mit dem Zahlungsassistenten (payment engine) erzeugen
  • diese Dateien in das Sparkassen-Programm S-FIRM importieren
  • von dort Ausgabe der Überweisungen an die Bank
• zu jedem Geschäftspartner haben wir maximal eine Bankverbindung in Business One erfasst (bei Kunden i.a. keine)

Für die Umstellung auf SEPA stellen sich nun zwei Aufgaben:

• die payment engine muss in Zukunft XML-Dateien nach ISO 20022 schreiben (statt bis bisher DTAUS/DTAZV).
  Wir spielen demnächst 8.82 PL11 + HF02 ein; ich hoffe, dass das damit möglich ist
  => Punkt (hoffentlich) erledigt
• wir müssen bei allen Lieferanten IBAN und BIC hinterlegen (von Hand zu viel Arbeit)
  • bei ausländischen Geschäftspartnern ist der BIC eh schon vorhanden, weil er immer schon nötig war
  • bei deutschen Geschäftspartnern müssten wir vor dem 01.02.2014 noch einen BIC haben (danach reicht IBAN alleine)
  • bei allen Geschäftspartnern ist die IBAN aus Kontonummer und BLZ zu berechnen und einzupflegen

Mir schwebt nun vor, dass ich

1. alle Bankverbindungen von Geschäftspartnern exportiere (SELECT * FROM OCRB),
2. aus den Feldern OCRB.BankCode und OCRB.Account (ggf. noch OCRB.Branch) die IBAN generieren lasse (ggf. auch den BIC für deutsche Konten)
   • es gibt da kostenpflichtige Angebote für Massenkonvertierung (z.B. IBAN-Service-Portal, IBAN-Rechner o.ä.)
   • das Ergebnis müsste in die Spalte OCRB.IBAN (und ggf. der BIC in OCRB.SwiftNum) eingetragen werden
3. diese Tabelle per DTW zurückimportieren
   • eine zusätzliche Kopfzeile bekommt die Objektnamen der DI-API, damit die DTW sie zuordnen kann
   • lediglich OCRB.AbsEntry und die veränderten Felder OCRB.IBAN und OCRB.SwiftNum müssen importiert werden, der Rest bekommt keine Spaltenüberschrift und wird von der DTW ignoriert

Die Frage ist aber, ob das so funktioniert - denn nach Einsichtnahme in die Tabellen OCRB ("BP - Bank Accounts") und OCRD ("Business Partners") ist mir nicht klar, wie diese zusammenhängen:

• die Standard-Bankverbindung steht fix in Spalten der OCRD - es gibt keinen Verweis auf eine Zeile in der OCRB
• in der OCRB hingegen gibt es zwar eine Spalte "OCRB.CardCode", aber da steht manchmal ein Wert passend zu OCRD.CardCode (GP-Code) drin, und manchmal ein Wert passend zu OCRD.DocEntry (Interne Nummer).
  Ich hätte da eher eine Konstruktion mit Primär-/Fremdschlüssel oder so erwartet, wie z.B. bei den Ansprechpartnern in OCPR...

Wenn ich nun die OCRB um die IBAN ergänze, wie wandert die dann rüber in den GP-Stamm, d.h. nach OCRD?

Ist das Vorgehen ansonsten richtig so, oder gibt es noch weitere Dinge zu beachten?

[Former Member · Accepted solution]

Hallo Thomas,

vergiss in den Tabellen OCRD den DocEntry bzw AbsEntry in OCRB. Diese sind nicht der Key zum JOIN. Wenn du die Daten auslesen willst, läuft das JOIN über den CardCode.

Wenn ich mich zudem recht erinnere, reicht es wenn du beim Business Master Data Import die Daten eingibst. Die DTW ist so intelligent und schreibt die Felder sowohl in die OCRD als auch in die OCRB (klappt aber nur wenn du pro GP eine Bankverbindung hast).

Um die Kontonummern auszulesen, würde ich ein Query in ungefähr der Form nutzen:

SELECT t0.cardcode, T1.[Account], T1.[IBAN], T1.[BankCode], T1.[SwiftNum] FROM OCRD T0 inner join OCRB T1 on t0.cardcode = t1.cardcode

Damit hast du eigentlich auch alle Felder wieder, die notwendig sind, um die Daten per DTW einzuspielen (egal ob in OCRD oder OCRB). Lediglich den Haeder der Importdatei musst natürlich anpassen. Ansonsten halte ich das Vorgehen wie du es beschrieben hast für Praktikabel. Wenn das Patch die SEPA Funktion mitbringt (kenne die Patch Notes nicht für HF2), sollte einer erfolgreichen Umstellung nichts im Wege stehen.

Grüße Steffen

[klein_thomas · Accepted solution]

Hallo Steffen,

vielen Dank die Zeit zum Reinlesen und Deine erschöpfende Antwort!

Ich stelle gerade fest, dass es (auch im per DTW frisch erzeugten) Import-Template für OCRD keine Spalte gibt gibt, über die man das auslesbare Feld OCRD.DflSwift wieder importieren könnte.

Auch wenn das natürlich zur Berechnung der IBAN bereits gefüllt sein müsste, so schließe ich hieraus, dass ich wohl besser die Bankverbindungen direkt in der OCRB aktualisiere (das ist vielleicht auch als Vorbild für andere der bessere Weg, bei denen mehrere Konten pro Kunde existieren).

Ich werde aber noch testen, ob die Veränderungen auch im GP-Stammdatensatz angezeigt werden.

edit: OCRD.DflSwift kann nicht per DTW in OCRD importiert werden

[K_Pauquet]

Hallo Thomas Klein,

nur FYI:

Es sind neue Informationen auf der SEPA Informationsseite im SMP zu finden, u.a. die Ankuendigung einer Expert Session fuer den 17.10.2013.

service.sap.com/partneredge/B1/sepa

Schoene Gruesse,

Kerstin

[Former Member]

Hallo Kerstin,

vielen Dank für die Info.

Leider wird die korrekte Abbildung der Lastschriften wohl erst sehr spät implementiert, aber immerhin ist etwas in Aussicht.

Gruß Thomas

[K_Pauquet]

Hallo Thomas,

Eventuell koennte man diese Frage in der Q&A Phase der Live-session stellen.

Schoene Gruesse,

Kerstin

[Former Member]

Hallo Thomas und alle SEPA Interessierten,

ich hatte am Wochenende Kontakt zum Projektverantwortlichen SEPA Konverter des DG Verlags der Genossenschaftsbanken.

Es ändern sich noch immer SEPA Regeln der Banken, wie aktuell vom 29.8.2013.

siehe

http://www.vr-iban-konverter.de/index.html

Hinweis:

Die Deutsche Bank hat zum 29. August ihre IBAN-Regel                               geändert. Diese Änderungen sind in dieser Version                               bereits enthalten.

Die Deutsche Bundesbank empfiehlt, bisher nicht                               eindeutige Bankverbindungen der Deutschen Bank erneut zu                               konvertieren.

----------

Das sollten alle Betroffenen im Auge behalten. Auf jeden Fall würde ich die alten GP Daten sichern oder Anfang Dezember konvertieren.

Hoffen wir, dass die Banken bald zu einer eindeutigen Definition kommen.

Gruss

Rita Lanz

[thomas_bartels]

Hallo Thomas,

wie du schon richtigerweise herausgefunden hast, wirst du beim Einlesen über die DTW Probleme mit dem BIC - Code bekommen, da das Feld nicht mit angeboten wird.

Da wir auch auf dieses Problem gestoßen waren habe ich mich mit meinem Programmierkollegen hingesetzt und wir haben ein kleines Tool entwickelt, welches Daten kombiniert aus der GP - Datei und der Bankenstammdatei (wegen Verbindung zur BIC) ausliest und für deutsche GP's gemäß einer europäischen Standardkonvertierung eine IBAN errechnet. Anschließend werden diese Daten wieder ins SAP B1 zurückgeschrieben. Des Weiteren kann man auch alle ausländischen Daten auslesen, diese im Tool manuell bearbeiten und zurückschreiben oder auch im Block als DTW - konforme Datei auslesen, damit über ein externes Konvertierungstool die IBAN's generiert werden können.

Wenn du an diesem Tool interessiert wärst, kannst du mir ja eine Nachricht zukommen lassen und wir treten noch einmal direkt in Kontakt.

Gruß

Thomas Bartels

[klein_thomas]

Hallo Thomas,

danke für das Angebot; wir haben die Konvertierung mittlerweile abgeschlossen.

Bei uns hat sich herausgestellt, dass die DTW die vorhandenen Einträge in der OCRB nicht einfach überschreibt (meine anfängliche Befürchtung), sondern vorhandene anhand des GP-Codes ergänzt. Somit konnte ich die IBAN importieren, ohne mir den BIC zu zerschießen, und damit wird der Import des BIC obsolet:

• bei deutschen Bankverbindungen reicht die IBAN
• bei ausländischen Bankverbindungen haben wir den BIC bereits eingepflegt, weil er auch vor SEPA schon benötigt wurde

Schönen Gruß

Thomas

[thomas_bartels]

An alle B1 - Kollegen,

wer bei seiner Konvertierung der Bankdaten noch nicht ganz so weit voran geschritten ist könnte sich vielleicht einmal folgenden Link anschauen:

http://www.inceptumgroup.de/?q=content/er-ist-da-der-sap-business-one-iban-generator-von-inceptum

Gruß

Thomas Bartels

[Former Member]

Hallo Thomas,

eine kleine Anmerkung: Mir wurde von der Bank mitgeteilt, dass das Format EBICS2.4 benötigt wird, dieses wird wohl erst ab 8.82 PL12 erstellt, mit den früheren Versionen kommt das veraltete Format EBICS2.3 raus, welches die Banken nicht mehr verarbeiten können.

Freundliche Grüße

Meike Gob

[klein_thomas]

Habe jetzt entdeckt, dass in der OCRB viele Doppeleinträge vorhanden sind, die sich nur im Eintrag OCRB.CardCode unterscheiden.

In dieser Spalte steht (s. Screenshot):

• einmal OCRB.CardCode = OCRD.CardCode (zu erwarten)
• einmal OCRB.CardCode = OCRD.DocEntry (unklar, wo der herkommt)

Ich habe testweise das Fenster "GP-Stamm / Zahlungsbedingungen" geöffnet und einen GP-Datensatz aufgerufen, der einen Doppeleintrag in OCRB hat.

Klick auf den Auswahlbutton bei "Bank Geschäftspartner" öffnet das Pop-Up "Geschäftspartnerbankkonten - Definition", aus dem sich folgende interessante Erkenntnisse ergeben:

1. es wird nur eine Bankverbindung angezeigt (obwohl OCRB zwei passende enthält)
2. wenn man Änderungen an der angezeigten Bankverbindung vornimmt, lassen sich diese nach Aktualisieren später in OCRB nachvollziehen - aber nicht bei beiden Einträgen, sondern nur in der Zeile, die den Verweis auf OCRD.CardCode beinhaltet

Wenn man die OCRB in Erzeugungs-Reihenfolge (also sortiert nach OCRB.AbsEntry) anschaut, fällt weiter auf, dass sich alle Duplikate mit Verweis auf OCRD.DocEntry im vorderen Teil der Tabelle befinden (bis Zeile 272 von insgesamt 650 Einträgen), aber i.a. nicht in direkter Nachbarschaft zu den Einträgen mit Verweis auf OCRD.CardCode.

Meine Schlussfolgerung aus alledem ist, dass alle Einträge, deren OCRB.CardCode nicht mit real vorhandenen Werten von OCRD.CardCode übereinstimmt, überflüssig sind.

• kann sich jemand erklären, wo die herkommen?
• kann man die Datenbank ggf. so bereinigen, dass dieser "Datenmüll" entsorgt wird?

[Former Member]

Hallo Thomas,

wir arbeiten uns gerade durch das gleiche Szenario. Da dieser Post schon älter ist, weiß ich nicht ob du deine Fragen beantworten konntest.

Was die fehlende SWIFT im DTW betrifft kann dir evtl. der folgende Post helfen:

http://scn.sap.com/thread/3265735

Was die Frage zu den doppelten Einträge betrifft kann man deinen Screenshot entnehmen, dass die Bankdaten nicht nur bei einem GP, sondern gleiche Daten bei verschiedenen GP's hinterlegt sind, daher wohl die doppelten Einträge.

Wir haben das Problem, dass wir für jeden Kunden verschiedene Kunden haben und ein Update über DTW die Reheinfolge der Konten in der OCRB durcheinanderwirft. Um das Problem zu lösen definieren wir dann einfach mit einem neuen DTW die Standard Bankverbindung.

Gruß

Mike

[klein_thomas]

Hallo Mike,

danke für den Hinweis zum Erstellen neuer Templates mit der DTW. Muss ich mal testen, ich bin gerade ein bisschen raus.

Eine andere Sache ist nach wie vor ungeklärt (auch für andere), nämlich die Herkunft der Doppeleinträge. Deine Vermutung dazu war:

Was die Frage zu den doppelten Einträge betrifft kann man deinen Screenshot entnehmen, dass die Bankdaten nicht nur bei einem GP, sondern gleiche Daten bei verschiedenen GP's hinterlegt sind, daher wohl die doppelten Einträge.

Nein. Da ich persönlich alle Daten nach B1 migriert habe, weiß ich genau, dass es bei uns nur 5-stellige GP-Codes gibt.

Bei den Doppeleinträgen kamen immer ein gültiger 5-stelliger GP-Code und ein 4-stelliger GP-Code vor (letzterer liefert, wenn man ihn in die Bildschirmmaske "GP-Stamm" eingibt, kein Ergebnis zurück!).

Falls Du oder jemand anderes dazu eine Erklärung hat, wäre ich sehr interessiert...

Gruß

Thomas