UETS-API-Integration im Lastenheft gefordert: Was beinhaltet das und wie kalkuliert man das im Angebot?

Die UETS-Dienste laufen in der Regel nicht über modernes REST, sondern über alte SOAP- und WSDL-Standards. Ihr müsst euch mit XML-Signaturen, X.509-Zertifikatsvalidierungen und speziellen Verschlüsselungsvorgaben von PTT rumschlagen. Da die Doku nicht gerade taufrisch ist, stellt euch auf einiges an Parsing-Frickelei in der Testumgebung ein.

Nehmt bei der Angebotserstellung diese drei Punkte als Sonderklauseln in den Vertrag auf: 1) Die Beantragung und das Durchlaufen der behördlichen Protokolle bei PTT liegt vollständig in der Verantwortung des Auftraggebers. 2) Für rechtliche Fristversäumnisse infolge von Ausfällen oder Timeouts der UETS-Webservices übernimmt der Auftragnehmer keinerlei Haftung. 3) Integrationstests erfolgen ausschließlich über die von PTT bereitgestellte Testumgebung.

Wir haben vor acht Monaten eine ähnliche Integration für ein Beratungsunternehmen umgesetzt. Der Code stand nach 12 Arbeitstagen, aber bis die PTT den Unternehmensvertrag freigegeben und die Test-IPs freigeschaltet hatte, vergingen ungelogen 45 Tage. Bindet euer Lieferdatum im Angebot bloß nicht an diese Bürokratie.

Versteckt diesen Posten im Angebot auf keinen Fall in anderen Modulen. Macht dafür eine eigene Position namens „Offizielles UETS-Integrationsmodul“ auf. Und setzt den Preis mindestens doppelt so hoch an wie bei einer normalen API-Integration, denn den Großteil der Kommunikation zwischen dem Kunden und der PTT werdet am Ende ihr abfedern müssen.

Nutzt Ihr Kunde das UETS-Konto als Privatperson/Einzelunternehmer oder als juristische Person? Bei individuellen Anwaltskonten läuft die Freischaltung der Webservices oft nach anderen Verfahren ab als bei Unternehmenskonten – wurde das vorab mit der PTT geklärt?

Kanzleien wollen am liebsten jede Zustellung vollautomatisch per API ins System ziehen. Aber wenn der Dienst morgen mal nicht antwortet und dadurch eine Frist versäumt wird, ist der Entwickler der erste Sündenbock. Wenn man die Haftungsgrenzen im Vertrag juristisch nicht bombenfest regeln kann sollte man sich zweimal überlegen, ob man sich das überhaupt ans Bein bindet.

Wir haben das vor zwei Jahren in einem Projekt mal wie einen ganz normalen SMS-Dienst behandelt und nur eine winzige Entwicklungspauschale angesetzt. Wegen der ständigen Sicherheitszertifikate der PTT Server-IP-Wechseln und ständig wechselnden Service-Responses ist am Ende die komplette Marge für den Support draufgegangen. Verlangt im Angebot unbedingt auch eine jährliche Wartungs- und Monitoring-Gebühr.

die ptt api prozesse sind echt unfassbar zäh. ehrlich gesagt packt in den vertrag unbedingt ne klausel rein dass freigaben seitens des kunden nicht zur lieferzeit zählen sonst machen die nachher stress wegen lieferverzug.

Betrachtet man den Prozess, ändert sich das Bild. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Dieses Thema ist archiviert. Wenn du das nicht von Anfang an schriftlich festhältst, gibt es später Streit.

Das habe ich auch erlebt.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

Ich hoffe, das hilft dir weiter.

Da ist mir noch ein Punkt unklar. Ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Ich probiere es aus.

Notiert, danke.

Ich schreibe kurz, wie das in der Praxis gemacht wird. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Viel Erfolg.

Ich bin derselben Meinung. Wer bei uets api integration hetzt, stolpert alle an derselben Stelle.

Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. Ich hoffe, das hilft dir weiter.

Wenn wir ins Detail gehen: Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Ich hoffe, das hilft dir weiter.