2. Backend Integration

Die funtrade Backend Integration ist eine kundenspezifisch ausgebaute Schnittstelle, über die externe Systeme (beispielsweise ein Webshop) Daten an funtrade übermitteln können.

2.1. Adressvalidierung

Dieser Abschnitt beschreibt die Validierung, die funtrade bei der Verarbeitung von FTML Transaktionen über die BEI Schnittstelle durchführt.

Wir sprechen von einer postalischen Adresse , wenn bei einer Privatadresse Sprache, Geschlecht oder Anrede, Nachname und Ort definiert sind. Bei einer Firmenadresse verlangen wir Sprache, Firma und Ort.

Wenn das Modul "E-Mail Only" (allgemeiner für nicht-postalische Adressen) aktiviert wurde, akzeptiert funtrade auch nicht postalische Adressen (ausser bei gewissen Transaktionen, siehe unten). funtrade prüft bei einer nicht-postalischen Adresse nur die Sprache.

Bei einer postalische Adresse wird (neben anderen Prüfungen) auch nach Strassen- und PLZ-Verzeichnis geprüft. Wenn die Adresse nicht validiert, bricht funtrade die Transaktion mit Fehler ab. Seit Version 10.28 (Januar 2012) kann dieses Verhalten vom Aufrufer mit requireValidMailingAddress = false verändert werden: funtrade lässt dann eine Adresse mit "falscher" postalischer Adresse durch und generiert eine Aufgabe "nichtKorrekteAdresse".

Bei einigen Transaktionen verlangt funtrade eine postalische Adresse, weil der zugehörige Prozess mit der Post weiter geht (hier nur die wichtigsten Fälle):

• Bei Spenden über Einzahlungsschein (Zahlungsart ESR) generiert funtrade eine Korrespondenz. Wenn es eine Post-Korrespondenz ist, muss die Adresse postalisch sein.

• Im Verkauf werden nur postalisch korrekte Adressen akzeptiert.

• Für Zusagen gilt: Bei Zahlungsart ESR oder DAU muss die Adresse postalisch sein.

• Für Publikationen gilt ebenfalls: Falls die Publikation Kanal Post hat, muss die Adresse postalisch sein.

• Bei Veranstaltungsteilnahmen (Anmeldungen) verlangt funtrade postalische Adressen.

2.2. E-Rechnungen mit Paynet

Das Modul Paynet erlaubt es grundsätzlich Einzahlungsscheine mit Referenznummer (ESR) elektronisch an Kunden zu versenden.

Die Organisation muss einen Dauerauftrag mit SIX-Paynet abschliessen und in einem Projekt mit SIX-Paynet und Arenae die Details für den visuellen Auftritt festlegen.

2.2.1. Funktionsübersicht

2.2.1.1. An- und Abmeldung

Kunden können sich für die elektronische Rechnung an- und abmelden: Im E-Banking -> Paynet Biller Liste -> "Ihre Organisation" und dann An- und Abmeldung. Bei der Anmeldung kann je nach Einrichtung noch anderes gesetzt werden.

Eine zweite Form der Anmeldung ist die so genannte Direktregistrierung, wo ein Kunde von seiner E-Banking Applikation beim Eingeben eines ESRs für ihre Organisation darauf aufmerksam gemacht wird, dass er oder sie diese Rechnung auch elektronisch bekommen könnte. Hier ist die Anmeldung direkt möglich.

Anmeldungen sind in funtrade in den FTML Transaktionen protokolliert und dann als Zahlungsverbindungen hinterlegt. Wichtigstes Datum ist die Paynet-ID (kurz PID).

2.2.1.2. Rechnungsstellung

Für eine Rechnungsstellung über Paynet muss funtrade die Daten wie ESR-Referenz, Konto, Betrag, Zahlungsfrist an Paynet übermitteln. Neben diesen Daten ist es notwendig, ein PDF mit der Rechnung mitzuliefern. Dieses Dokument braucht aber selbst keinen ESR mehr.

In den folgenden Bereichen ist in funtrade die Paynet Rechnungsstellung vorgesehen.

2.2.1.2.1. Zusagenfakturierung

Die Zusage hat den Zahlungsmodus Paynet und in der Zusagenfakturierung gibt es einen speziellen Lauf für Paynet Fakturierungen.

Wenn hier monatliche Fakturierungen gemacht werden, muss man darauf achten, dass die Kommunikation (das PDF) auch entsprechend angepasst wird (wenn gewünscht).

2.2.1.2.2. Korrespondenz

Eine Korrespondenz wird ausgelöst bei Spenden über Internet und ESR (nicht bei Kreditkarten Bestellungen) und bei telefonischen Anfragen nach einem Spenden-ESR. Wenn der Spender eine aktive Paynet-Zahlungsverbindung hat und die Korrespondenz im PDF Format vorliegt, schickt funtrade die „Rechnung“ über Paynet.

2.2.1.2.3. Verkauf und Mahnwesen

Im Verkauf wird neben der physischen Ware ein ESR als Paynet Rechnung losgeschickt.

2.2.2. Administration in funtrade

In funtrade ist die Tabelle Paynet Transaktionen eingerichtet. Dort sind alle Transaktionen inkl. den verschickten PDFs sichtbar.

2.3. Kreditkarten Belastungen mit Saferpay

Das Modul zur Kreditkarten-Belastung mit Saferpay ist in diesem Kapitel beschrieben. Die Verwendung in funtrade ist unabhängig vom gewählten Provider. Dieses Kapitel beschreibt deshalb nur die Einstellungen und Parametrisierungen spezifisch für den Provider Saferpay.

2.3.1. Erzeugen der Saferpay Schlüssel

Mit den Zugangsdaten von Saferpay kann die Schlüsselerzeugung gemäss dem Dokument "Saferpay Authorization Interface V4.1.3 DE" durchgeführt werden. Das Resultat ist ein Verzeichnis, in dem sich alle Konfigurations- und Schlüsseldateien befinden.

2.3.2. Einbinden der Saferpay Konfiguration

In der funtrade Backend Integration müssen die Saferpay Dateien eingebunden werden. In ft-bei.properties brauchen wir zwei Einträge:

#
# Saferpay
#
ch.arenae.funtrade.ws.saferpay.configDir=/path/to/config.dir
ch.arenae.funtrade.ws.saferpay.accountId=my-account-id

2.4. SMS Spenden und Freetext

Eine Spezialität sind SMS Spenden, die über die BEI in funtrade ankommen. Man hat dort typischerweise gar keine Daten zur Person ausser der Mobile-Nummer. Wenn zusätzliche Daten kommen, sind sie aber nicht strukturiert. Aus diesem Grund gibt es das Feld FreeText , das beliebige unstrukturierte Information aufnehmen kann.

Wenn FTML Transaktionen mit FreeText in funtrade ankommen, erfasst funtrade eine Aufgabe vom Typ "ftmlFreeText", sofern sie in den Einstellungen zu den Aufgaben aktiviert wurde.

2.5. Verkauf und Produkte

Ein Webshop kann Produktedaten aus funtrade abfragen (Services getProduct() und getUpdatedProducts() ). Welche Produkte von diesen Services gezeigt werden und aus welchem Lager die Bestandesdaten kommen, kann mit dem Systemparameter fwwp eingestellt werden: fwwp=lagerort,medium . Nur Artikel mit dem angegebenen Mediumscode und einer expliziten Medienartikelverknüpfung mit eingetragenem Datum werden berücksichtigt.

Aufträge kommen als FTML-Transaktionen über den TransactionService oder den OrderService als zu funtrade . Auftragsart, Bestellart, Verkäufer und Medium können in einem Regelsystem in der Tabelle Datenaustausch / Tabellen / FTML-Einstellungen / Auftragsimport definiert werden.

Wenn gewünscht, kann funtrade bei Order-Transaktionen eine Versandkosten-Berechnung durchführen. Dazu wird der Auftrag im checkTransaction übergeben und funtrade aktualisiert den Auftrag mit berechneten Versandkosten (und auch mit Rabatten). Dieses Feature ist nicht bei allen Kunden eingeschaltet (direkt im Code, kein Systemparameter). Die eigentliche Berechnung ist in Versandkosten-Berechnung beschrieben.

2.6. Visit

Das FTML Visit Element erlaubt es, anderen System in funtrade ein I-Ereignis zu erfassen.

Der Kanal für das neue Ereignis wird im Systemparameter kanalForFtmlQuelle definiert.

2.7. Zusagen

Zusagen können mit submitTransaction() und einem PledgeItem oder (äquivalent) mit PledgeService.addPledge() übermittelt werden.

Akqui-Ereignisse zu FTML-Zusagen können in der Tabelle System / Tabellen / Systemverwalter / Akquisitionsereignisse definiert werden. FTML hat auch die Möglichkeit, dass Akqui-Ereignisse direkt übergeben werden können.

Wenn Zusagen direkt auf dem Web bezahlt werden, gilt das als FirstPayment und wird so auch übertragen in FTML. In der Tabelle Datenaustasch / Tabellen / FTML Einstellungen / Zusagen First Payment kann diesen Zahlungen ein Ereignis zugeordnet werden.