CENTRIC BCM Bank & Cash Management Alexander Klauss Oracle Applications

Centric IT Solutions GmbH

Agenda Überblick BCM • • • • •

Module Verfügbarkeit Ablauf Zuordnung von Bankauszugspositionen Zusammenfassung

Das Kundenprojekt Produkt “Look & Feel” Q&A

Automatische Bankauszugsverarbeitung mit dem Centric BCM Modul für JD Edwards EnterpriseOne und der Praxiseinsatz an einem Kundenbeispiel

Überblick BCM – Module Banking & Cash Module (BCM). Module in JD Edwards: Grundlegende Funktionen und Zielsetzung: automatischer Import von Bankauszügen; automatische und effiziente manuelle Verarbeitung von Bankauszügen; Weitergabe an die Standard JD Edwards EnterpriseOne module; Automatische Zuordnung von Bankauszugspositionen zu offenen Posten Debitoren und Kreditoren sowie maschinelle Buchung von Hauptbuchtransaktionen; Manuelle Zuordnung von Bankauszugspositionen zu offenen Posten Debitoren und Kreditoren Generierung von nicht zugeordneten Zahlungen, etc; Effizienzsteigerung im Cash Management und bessere Nachvollziehbarkeit unf Auditierbarkeit Mit dem BCM Modul können typischerweise ca 90% der Bankauszugspositionen maschinell verarbeitet werden

Verfügbarkeit Verfügbare Versionen: Xe, ERP8, 8.9, 8.10, 8.11, 8.12, 9.0 Fat clients, Citrix und HTML Banking Formate (MT940): Bereits mehr als 70 layouts verfügbar ES MT940 Fortis, DE MT940 Deutsche Bank, BE MT940 ABN Amro Access Online, NL MT940 Rabobank, SE FS1 Nordea, UK MT940 HSBC, FR MT940 Societe General … and many more Austria, Belgium, Denmark, Finland, France, Germany, Italy, Luxemburg, Netherlands, Norway, Poland, Spain, Sweden, Switzerland, UK, USA, etc.

Zusätzliche Formate können schnell zur Verfügung gestellt werden “unedited bank statements” (upload Excel) EDI Files

Alle Währungen mit 0 oder 2 Nachkommastellen

Bank Cash Modul – Ablauf

MT 940 bank statement file Bank / EDI (JP Morgan, ING, Deutsche Bank, HSBC, RBS, Rabo,…..)

Electronic banking Import statement(s)

Automatic matching EnterpriseOne BCM module

Work with statements: review/approve matching, manual matching etc

Process Bank Statement

EnterpriseOne Standard tables History BCM

Inquiries/Reports

Yellow = BCM within EnterpriseOne

Bank Cash Modul - Funktionen Debitorenzahlung

Security auf Unternehmen

Nicht zugeordnete Zahlung Zahlungs Avis Kreditorenzahlung

Direkte Aktualisierung des Banksaldo

Statistik pro Bankauszug

Hauptbuchtransaktion Stornierungen (Rücklastschrift)

Historische Bankauszüge und erfolgte Zuordnung dokumentiert (Auditierung!)

Erzeugen von Debitoren OP EDI: REMADV Erzeugen von Kreditoren OP Wechsel/ Scheck

Volle Kontrolle über Zuordnung und Verarbeitung von Bankauszugspositionen

Kunden-/ Lieferantenbankkonto aktualisieren Maschinelle Zuordnung von nicht zugeordnet. Zahlungen (beliebigen Ursprungs)

(Kundenspezifische) Ausbuchung von Kleindifferenzen

Automatische Zuordnung Zuordnungsroutinen können Kunden, Bankkonten und weiteren Elementen zugeordnet werden und bestehen aus einem oder einer Komination von mehreren Zuordnungsalgorythmen: Bekannter Zahler: (Basiert auf Bank Konto des Kunden) Rechnungsnummer (8 Stellen) Letzten 7, 6, 5, 4 or 3 Stellen Rechnungsnummer Gesamter offener Betrag Genauer Einzelbetrag Nur eine offene Rechnung Älteste Rechnung (LIFO) Referenzfeld Buchungstext “Through” Algorythmus

Unbekannter Zahler: Rechnungsnummer (variabel) Adressnummer Auszugsnummer Zahlungsavis Versandbestätigung Auftragsnummer Referenzfeld Buchungstext

Und: Hauptbuchtransaktion. HB-Klasse (Schlagwort)

Kreditorenrechnung Rechnung / HB-Klasse (Suchwort)

Wechselverarbeitung mit BCM 1/2 (JDE Standard) Rechnung erstellen • Sales Order Processing / Sales Update (R42565 + R42800) • Manuelle Eingabe (P03B2002) • Zahlungsmittel muss “D” sein Rechnungsdruck mit Wechsel • Oder Auszugsdruck mit Wechsel (R03B500X) Kundenwechsel erfassen • Prüfen (P0011) und buchen (R09801) Wechsel einreichen • Prüfen (P0011) und buchen (R09801)

Wechselverarbeitung mit BCM 2/2 (JDE Standard)

Arbeiten mit Bankauszügen Bankauszüge verarbeiten • Mit oder ohne automatische Buchung

BCM – Zusammenfassung Vollständig in JD Edwards Enterprise One integriert MT940 Standard Wartung – regelmäßige Updates Lernendes System Manuelle Zuordnunug auf einem Bildschirm für A/P, A/R, G/L Historische und aktuelle Daten auf einem Bildschirm Einfachste Bedienung – wenige Arbeitsschritte Kreditkartenabrechnung oder Shop Anbidung möglich (Wie eine Bankauszug) Wechsel/ Schecks möglich

Auswahl an Kunden Afvalenergiebedrijf Amsterdam BAS Computers Beko Beter Horen/Amplifon Beurtvaart Bolsius Centric InOne, DE City of Amsterdam, Almere, Venlo Fanuc, LU IJsselmeerbeton IFN-Holding (Internorm), AT J&J (Depuy/Ethicon), BE Kaemingk Keune Kleyn Trucks Meester Stegeman

Norgren UK, DE, CZ Nintendo of Europe Oerlikon, DE Randstad Regifarm RioTinto FR, IT, BE, AT, ES Sara Lee Foods Sennheiser Schouten Products Shimano Skandia Vers., DE (AT+CH) Spirax Sarco, UK Talens TNT/CEVA W.L. Gore Zwanenberg Food Group And others....

Das Kundenprojekt Die folgenden Ausführungen beruhen auf den Aussagen der Projektleitung der BCM Einführung auf Anwenderseite

Prozess vor der Einführung 4,7 FTE waren mit der Verarbeitung von Bankauszügen im Shared Service Center beschäftigt Die Bank Statements wurden in der Regel zunächst ausgedruckt Per Excel Sheet oder manueller Suche der Debitoren OP im System wurde eine Zuordnung vorgenommen Bei Kundenrückfragen wurde der Bankauszug (Papier) manuell durchsucht Partiell wurde ein externes Bankmodul eingesetzt, wo über eine Schnittstelle der Export der Debitoren OP’s und der Import der Bankbuchungen nach erfolgter externer Verarbeitung stattgefunden hat. Es hat sich jedoch gezeigt, dass der Einsatz dieser Schnittstelle zu viele Schwachpunkte aufwies, so dass dieser Weg im Konzern nicht konsequent weiter verfolgt wurde.

Auswahlprozess Gesucht wurde eine “Cash Application”, kein Treasury oder Debitoren Management Modul. Damit wurde BCM genau der richtige Funktionsumfang zugebilligt. Ein weiterer entscheidender Punkt für die Entscheidung BCM zu verwenden, war die Integration in JD Edwards, statt eines Upload und Download per Schnittstelle zu einem externen System. Auch aus Anwendersicht wurde als Vorteil angesehen, dass sich BCM von der Oberfläche und vom Ablauf in JD Edwards nahtlos integriert.

Warum überhaupt eine „Cash Application“ Ziel: Effizienz im Bereich Debitoren steigern, also mehr Bank Transaktionen mit weniger Aufwand und Fehlern verarbeiten können. Die Strukturierung von Teilen der Buchhaltung in zentralisierte Shared Service Center erleichterte die Einführung einer solchen Applikation. Europaweit sollte die Verarbeitung von kompletten Bankauszügen maschinell erfolgen. Vor allem im Bereich der Debitorenzahlungen erhoffte man sich eine schnellere und genauere Zuordnung.

Erfahrungen 1 von 4 Technische Installation • Die technische Installation war unkompliziert, fand durch das Einspielen eines ASU (Automated Software Update) in den USA statt

Konfiguration/ Einführung • Der ursprüngliche Plan sah vor, dass zunächst 3 Firmen einen Probebetrieb aufnehmen sollten • Im 2. Schritt sollten dann 5 weitere Firmen folgen • Im Verlauf des Projektes wurde aufgrund der guten Testergebnisse entschieden, alle Firmen parallel live zu schalten

Erfahrungen 2 von 4 Projektverlauf • Projektstart: Januar 2010 • Produktivstellung: April 2010 • Das Projekt wurde parallel zum Jahresabschluss geführt, so dass ca. 6 Wochen nicht am Projekt gearbeitet werden konnte! • Externer Beratungsaufwand: 5 Tage • Interner Aufwand: Wesentlich mehr, wurde jedoch nicht gemessen • Es gab (lediglich einige Detailprobleme) keine wesentlichen Störungen im Projekt

Schulung • 1 Tag Schulung geplant • Lediglich 3 Stunden realisiert • “Training on the Job” in 6 Wochen Testphase

Erfahrungen 3 von 4 Praxisbetrieb • Seit April 2010 live • Gute Effizienzsteigerung • Um 6 Uhr sind die Bank Statements im System und alle maschinellen Aktivitäten abgeschlossen • Vor der Umstellung waren die Bankauszüge immer mit einem Tag Verzögerung verarbeitet, jetzt ist das System tagesaktuell • Lernendes System: Wie bewähren sich die Zuordnungs-Algorithmen?

Erfahrungen 4 von 4 Rate der Zuordnung: • 73 – 75% im Durchschnitt der 29 im System abgebildeten Konten • 200 Transaktionen pro Tag mit einer Zuordnungsrate von 69 % - 88% beim Konto mit der höchsten Aktivität • Auch andere Zahlungen können erfolgreich zugeordnet werden (Kreditoren), bei Sachbuchungen ist die Automatisierung bei 100% • Momentan ist die Verarbeitung von Zahlungsavisen noch nicht automatisiert, dies würde die Rate der Zuordnung nochmals wesentlich verbessern

Nächste Schritte Roll out nach Asien Geplant sind ein Training und die (geführte) Verwendung von Echtdaten im Testsystem – sozusagen als „training on the job“ Die Automatisierung im Bereich Verarbeitung von Zahlungsavisen soll als rein internes Projekt in Kürze erfolgen

Fragen?