diff --git a/Stundensheet.xlsx b/Stundensheet.xlsx
index fda1bf78..2fcc4f89 100644
Binary files a/Stundensheet.xlsx and b/Stundensheet.xlsx differ
diff --git a/nsw/Treffen_Zakel_dbh_18.2.2015.txt b/nsw/Treffen_Zakel_dbh_18.2.2015.txt
new file mode 100644
index 00000000..db83c2b0
--- /dev/null
+++ b/nsw/Treffen_Zakel_dbh_18.2.2015.txt
@@ -0,0 +1,49 @@
+- Testing: Ein Service-Endpunkt inkl wsdl wird ab Ende des Monats Feb. zu Verfügung stehen
+- Wir müssen ebenfalls einen Service-Endpunkt implementieren für die "proaktiven" Antwortnachrichten
+-> ein Client Only Ansatz ist das somit nicht und für uns mit zusätzlichem Aufwand verbunden. Ebenfalls unklar die
+von dbh erwartete Funktionssignatur - so müssen sie für alle Schnittstellenpartner eine eigene Antwortschnittstelle implementieren
+dbh implementiert eine Webanwendung, die bis Ende April zu Verfügung steht. Diese Komponente ist der letzte Bestandteil.
+Außerdem soll es eine statistische Auswertung geben (wurde nur in einem Nebensatz erwähnt)
+- doppelte Schiffsanmeldungen werden vom System nicht abgefangen .. dafür ist der Endanwender selbst zuständig.
+- Zeiten sind UTC
+- Zeichensatz, unicode: warten auf Antwort von dbh
+- nach der im NSW erfolgreichen Anmeldung oder generell Meldung zu einem Schiff soll das System ein Protokoll
+erstellen, daß der Kunde als "richtig" gegenzeichnet. Sind Einwände vorhanden kann noch ein Update hinterhergeschickt
+werden.
+- noch offene Fragen: wir wird von dbh ein Meldungs-Reset umgesetzt (muss auch über die Schnittstelle getested werden)?
+- wsdl für response muss eigentlich auch von dbh kommen?
+- Datenbankdesign: Um eine Historie zu erhalten können die Daten nicht nur in einer Maske / einer Tabelle gehalten werden?
+
+Zu überlegen:
+- wie "merkt" das Frontend eine Änderung eines Datensatzes im Backend?
+- brauchen wir überhaupt 2 Datenbanken? Würde es nicht ausreichen, ebenfalls auf die Wetris Tabellen zuzugreifen und in 
+derselbe DB einfach nur ein paar neue Tabellen anzulegen. Damit könnte man die ggf. komplizierte Replikation sparen.
+
+Es muss einen Meldungs / Vorgangskopf und zeitlich sortierte Vorgangspositionen geben, in denen dann die eigentlichen
+Feldwerte enthalten sind, außerdem ein NSW Status (Kommunikationsstatus mit der Schnittstelle) und ein Zeitstempel.
+Damit wird dann auch eine Historie sichtbar. In der Hauptmaske ist der jeweils aktuelle Zustand angezeigt (analog Zollanwendung APD (dbh))
+
+Außerdem eine Schiffsanlauf-Kopf Tabelle, in der die IMO, Zeitstempel Hafen und VISIT-ID enthalten sind. Alle Meldungen referenzieren auf 
+diese Tabelle. Damit ist ein Schiffsanlauf in einem Vorgang zusammengefasst. Dadurch wird eine Vorbelegung von
+Feldern aus historischen Daten zur leichteren Eingabe möglich.
+
+Validierungs-Regeln für die Eingabe von Meldungen sollten direkt in der Maske eingebaut sein, nicht im NSW Service,
+damit hier kein Round-Trip notwendig wird. Diese Regeln müssen leicht änderbar sein.
+
+
+Zeitplan für die NSW Umsetzung beim BSMD
+
+So bald wie möglich:
+- aktuelle Zugangsdaten zu den Testsystemen (Firewall, VPN): Kersten
+- Installation SQL Server auf NSW Rechner (Express Edition, gleiche Version wie Wetris): Kersten
+
+Bis Ende des Monats:
+- Anlegen der Datenbankstruktur für die fehlenden Felder über EasyLogic: Kersten, Christin, (Michael), Daniel
+- Anlage der Referenztabelle bzw. Lieferung der Screenshots für die Zuordnung der Felder: Christin
+- Import der aktuellen .xsd Daten und Anlage der Service-Struktur NSW Rechner: Daniel
+
+Bis Ende März:
+- Abfrage von VISIT-ID / Einfache Schiffsmeldung inkl Test mit dbh Schnittstelle: Daniel
+
+Bis Ende April:
+- Implementierung der restlichen Meldungsklassen (außer Gefahrgut): Daniel