Geekly articles weekly

Wie ich kein elektronisches CTP gekauft habe

Ich denke, viele Autobesitzer von Habr und geektimes haben bereits von der Möglichkeit gehört, OSAGO elektronisch zu kaufen. Diese Gelegenheit erschien vor ungefähr sechs Monaten, ich hatte das Glück, sie erst jetzt an mir selbst auszuprobieren.

Die Situation mit der obligatorischen Kfz-Haftpflichtversicherung in einigen Regionen, wie z. B. meinem Uljanowsk, ist sogar absurd - Agenten verkaufen Versicherungen nur mit unnötigen Begleitversicherungen für 1000-2000 Rubel, und in den Versicherungsunternehmen selbst stellen sie eine Versicherungspolice pro Stunde aus, wodurch riesige Warteschlangen entstehen, ein Ort, an dem müssen am Morgen ausleihen.

Daher sieht die Möglichkeit, eine Versicherung elektronisch zu kaufen, ohne von einem Stuhl aufzustehen, wie eine magische Lösung für Kopfschmerzen aus.

Mit Blick auf die Zukunft kann ich sagen, dass Sie OSOSAGO nur beantragen können, wenn Sie dieses Auto zuvor auf die übliche Weise versichert haben - die Daten werden gemäß der vorherigen Richtlinie überprüft.

Nachdem ich eines Morgens festgestellt hatte, dass die Versicherung heute nicht mehr gültig ist, beschloss ich, das neue System auszuprobieren. Es wurde ein Epos von drei Tagen mit Freuden und Erwartungen, Hoffnungen und Enttäuschungen.

Und um ehrlich zu sein, schien niemand an der Qualitätsarbeit dieses Systems interessiert zu sein.

Aber das Wichtigste zuerst.



Tag 1



Ich habe einige große Unternehmen ausgewählt, von denen ich wusste, dass sie auf der ersten Seite der Suchergebnisse für „elektronisches OSAGO“ auftauchen, und bin auf der Suche nach eOSAGO zu ihren Websites gegangen.

Das erste, was sich herausstellte - trotz des erklärten Verkaufs von elektronischem OSAGO -, arbeiten Unternehmen nur sehr begrenzt mit ihnen zusammen. Rosgosstrakh ging vor mehr als einem Monat zur "technischen Arbeit". Alfastrakhovanie - nur für diejenigen, die sie zuvor mit "Papier" versichert hatten. Einige Unternehmen boten die Möglichkeit, eOSAGO nur für diejenigen zu kaufen, die in bestimmten Regionen registriert sind, hauptsächlich in Moskau und St. Petersburg. Die Möglichkeit einer elektronischen Versicherung dürfte jedoch den potenziellen Kundenstamm aus den Regionen mit physischer Präsenz im ganzen Land vergrößern.

Okay, entschied ich mich und fing an zu zeichnen.

Dann wurde klar, dass das System nicht debuggt wurde.

Die erste Seite, auf die ich stieß, war Tinkoff Insurance .
Tinkoff ist berühmt für die Bequemlichkeit seines Online-Bankings, wie ich es von der Versicherungsschnittstelle erwartet habe. Aber sie überraschten. Erstens stellte sich heraus, dass die vorläufige Versicherungssumme für mein Auto und die Region aus irgendeinem Grund halb so hoch war wie erwartet (2.800 Rubel statt 5.500 Rubel, wie alle anderen Versicherungsunternehmen erwartet hatten).



Aber die Bequemlichkeit der Benutzeroberfläche war einfach "oben". Zusätzlich zu den Feldern zur Eingabe der Registrierungsadresse für den Reisepass gab es aus irgendeinem Grund Felder zur Eingabe der tatsächlichen Wohnadresse, die obligatorisch waren. Weder das Kontrollkästchen "Dieselben Daten verwenden" noch die Möglichkeit, sie abzulehnen. Außerdem mussten dieselben Daten dreimal eingegeben werden - der Versicherungsnehmer, der Autobesitzer und schließlich der Fahrer.



Ich habe den gesamten Datenbereich auf der Seite ausgefüllt, auf "Neu berechnen" geklickt und ... Und nichts, die Seite hing 5 Minuten lang. Nach 5 Minuten wurde eine Fehlermeldung angezeigt, die besagt, dass Sie sich an das nächstgelegene Büro wenden, um ein klassisches CTP zu beantragen, oder sich an einen Berater wenden. Der Berater stellte sich als absolut nutzloser Roboter heraus - er antwortete mit Standardphrasen: "Elektronisches CTP wird unabhängig auf der Website ausgestellt. Wenn Sie sicher sind, dass alle Daten korrekt ausgefüllt sind, schreiben Sie an die auf der Website angegebene Support-E-Mail." Übrigens konnte ich diese E-Mail nirgendwo finden. Ich fragte den Berater - und er verschwand für immer.

Ich war immer noch begeistert und entschied, dass hier immer noch alles nur debuggt wird, lasst uns weitermachen.
Die nächste Versicherung war RESO. Hier konnte ich mich zum Zeitpunkt der Eingabe der Passdaten des Versicherten nicht registrieren, sie haben den Test bei der RSA einfach nicht bestanden. Freunde auf Twitter schrieben, dass sie es erfolgreich geschafft haben, sich dort zu versichern, indem sie technischen Support geschrieben haben, was darauf hindeutete, dass Sie "richtig" eingeben müssen. Ich schrieb ihnen zur Unterstützung, wartete aber nicht auf eine Antwort.

Dann ging ich zur VSK- Website . Die Schnittstelle dieser Versicherung ist meiner Meinung nach die erfolgreichste, angenehmste und nachdenklichste. Daten werden in logische Blöcke gruppiert, es muss nichts erneut eingegeben werden, die Überprüfung erfolgt sofort durch Blöcke während des Füllens.



Aber hier ist alles nicht so gut geworden :) Ich habe alle Daten ausgefüllt, sie haben die Verifikation (!) In PCA erfolgreich bestanden. Ich bestätigte die Berechnung per SMS, klickte zum Bezahlen und griff in meine Brieftasche nach einer Karte ... Aber nach ein paar Minuten Wartezeit erhielt ich die Nachricht, dass die Richtlinie den PCA-Check nicht besteht, mit dem Code 024. Wenn Sie lesen, stoßen viele Menschen auf diesen Fehler.

Der folgende Kommentar erschien in der geektimes VKontakte-Gruppe :
Hmm, aber ich weiß, welche Fehler er dort gefangen hat. Letzteres war mit der doppelten Richtliniennummer in der Datenbank verknüpft. Und der erste war ein Fehler beim Senden von Daten an die PCA (absichtlich aus Großbritannien).


Wenn dies zutrifft, erklärt dies im Prinzip die künstliche Begrenzung des Umsatzes durch Versicherungen vollständig.

In UralSiba hat an diesem Tag nicht Schnittstelle Versicherung Designarbeit (und am nächsten Tag gab er den gleichen Fehler wie alle anderen).

Nachdem ich alle Versicherungsunternehmen ausprobiert hatte, von denen ich weiß, dass sie e-OSAGO betreiben, beschloss ich, bis zum Ende zu gehen, und begann, alle Versicherungen nacheinander gemäß der Liste auf der PCA-Website auszuprobieren .

Mehrere Versicherungsschnittstellen sahen aus wie Zwillinge. Es stellte sich heraus, dass es bereits jemandem gelungen war, eine vorgefertigte PolisOffice- Lösung zu erstellen , die an Versicherungen verkauft wurde. Jedoch sofort.

Finde die Unterschiede

Bei Parity-SKFür den Verkauf von Policen wurde im Allgemeinen die 1C 8.3-Schnittstelle unter der strengen Anleitung der beigefügten Anweisungen verwendet, was mich sehr amüsierte.



Das Ergebnis war überall das gleiche - alle Daten haben die Überprüfung in der SAR-Datenbank bestanden, aber zum Zeitpunkt der endgültigen "Registrierung" der Richtlinie vor der Zahlung haben sie die Überprüfung nicht in derselben SAR bestanden.

Es war schon später Abend und es war sinnlos, die Versicherung natürlich anzurufen. Ich ging durch mehrere thematische Ressourcen. Die Anzahl der Beschwerden in den Foren erweckte den Eindruck, dass elektronische Policen nach dem gleichen Prinzip wie auf Papier verkauft wurden, mit der maximalen Verzögerung des Prozesses - die Policen waren beendet, dann war die Warteschlange für die „Inspektion eines Autos“ für eine Woche geplant. Ich weiß nicht, ob das so ist. Viele schrieben, dass ihnen geholfen wurde, indem sie sich an ihre Versicherungsgesellschaft wandten, um die Daten der Police zu überprüfen. Gemäß den Daten der vorherigen Police werden die Daten in der SAR überprüft. Ich ging zu meiner Versicherungswebsite und schrieb mehrere Anträge für alle möglichen Adressen. Gleichzeitig schrieb er an mehrere Versicherungsunternehmen, bei denen ich versuchte, eine E-Police zu beantragen, und ging schlafen.

Tag 2



Am frühen Morgen weckte ich einen Anruf von meiner Versicherung. Das fürsorgliche Mädchen entschuldigte sich für die Unannehmlichkeiten, überprüfte alle Daten und schickte die Richtlinien des letzten Jahres erneut an die Datenbank. Laut ihr dauert die Aktualisierung der Datenbank 30 Minuten - 3 Stunden.

Jetzt haben sich die Angaben aller Versicherungsunternehmen geändert - die Daten wurden zum Zeitpunkt des Ausfüllens der Adresse des Versicherungsnehmers nicht mehr überprüft, einige gaben einen bestimmten Code zurück - AddressRSACode. Die andere Hälfte der Benutzer ist auf diesen Fehler gestoßen, der den Fehler in der letzten Phase nicht erreicht hat. Viele versuchten, ihre Adresse mit möglichen Fehlern und Tippfehlern zu schreiben, und dies half ihnen. Aber nicht in meinem Fall.

Zu diesem Zeitpunkt wusste ich bereits, dass AddressRSACode in der XML-Datei, die die Versicherung über SOAP für die Registrierung bereitstellt, ein bestimmtes Feld mit einem langen Dezimalcode ist, der dem KLADR-Code ähnelt.
Die Adresse wurde auch von KLADR ausgewählt, und hier habe ich einen Hinweis bekommen. Meine Adresse lautet Avenue zum 50. Jahrestag des Komsomol, 24.
In KLADR gibt es kein solches Haus, mein Haus wird als 24/20 registriert, da es an der Kreuzung zweier Straßen steht. Ich habe zu Hause alle Optionen ausprobiert (24/20, 24A usw., 24 Gebäude 20), aber das ergab keinen Sinn. Wieder rief ich meine Versicherung an und gab an, wie sie ein Haus auswählen - aus der Auswahl oder manuell eingeben. Die Antwort war - die Straße - mit der Liste von KLADR, dem Haus - manuell auswählen. Ich habe darum gebeten, das Haus 24/20 zu stellen, wie in KLADR, aber sie haben mich abgelehnt, weil die Passdaten für die Registrierung Haus 24 sind und sie kein anderes schreiben können. Bürokratie, aber fair. Alle Daten in der Richtlinie wurden mir noch einmal auf einen Brief überprüft und erneut an die Datenbank gesendet.

Meiner Meinung nach besteht das Problem darin, wie die Versicherung und die PCA-Basis selbst diesen Code basierend auf der Adresse generieren. Und wie sie die Hausnummer verarbeiten, die nicht in der KLADR steht. Anscheinend wird an einer Stelle ein Code aus der Hausnummer generiert, an einer anderen - an einer anderen. Aber das ist reine Vermutung.

Natürlich war es möglich, weiter zu schlagen und sich auf den Weg zu denen zu machen, die alles entwickelten. Es ist jedoch klar, dass die Versicherung keine Abteilung mit der Entwicklung eines solchen Systems beauftragt, und Sie können mehr als eine Woche damit verbringen, nach geeigneten Technikern des Auftragnehmers zu suchen, die sich darum kümmern.

Nachdem ich verstanden hatte, dass die Versicherungsmöglichkeiten für den Zugriff auf die Datenbank ausgeschöpft waren, wandte ich mich direkt an die RSA. Am Telefon wollten sie mich nicht mit denen verbinden, die für IP für OSAGO verantwortlich sind. Sie erklärten höflich, dass die SAR selbst keinen „Online-Zugang“ (ihr Ausdruck) zur Datenbank habe. Nur Versicherungen können mit der Datenbank arbeiten.
Beachten Sie, was für ein interessanter Ansatz - der Basisoperator ist nicht für die Basis verantwortlich, hat keinen Zugriff darauf und spielt herum. Das heißt, letztendlich trägt niemand die Verantwortung für die Richtigkeit der Daten in der Datenbank.

Die Unterstützung durch Versicherungsunternehmen war ebenfalls sehr enttäuschend - UralSib und VSK antworteten mit Standardantworten und sagten, wenn dies nicht klappen würde, würde dies technische Schwierigkeiten bedeuten, wenden Sie sich an das Büro. RESO einfach ignoriert.
Zetta Insurance war angenehm ausgezeichnet - laut dem Antrag in meinem persönlichen Konto, einem zurückgerufenen Mädchen, das vorschlug, mit Adressfeldern zu experimentieren, wurde diese Versicherung für mich persönlich durch ihre Freundlichkeit in Erinnerung gerufen (obwohl sie keine sehr bequeme Oberfläche ist).

Tag 3



Am Ende habe ich die Versicherung mit meiner Versicherung verlängert. Sie hatten es satt, Aufzeichnungen in der Datenbank zu bearbeiten, und schlugen vor, dass ich die Richtlinie erneuere, ohne in der Schlange zu stehen und das Auto zu inspizieren. Das Mädchen und ich kamen an und bekamen die Police in 15 Minuten. Es war die schnellste Registrierung der Police in den letzten 3 Jahren.
Dieses Mal habe ich genau beobachtet, welche Daten der Bediener in der Richtliniendatenbank speichert. Danach habe ich zu Hause erneut versucht, eine elektronische Richtlinie mit denselben Daten herauszugeben - trotzdem ohne Erfolg.

upd


Zentralbankposition :
Shvetsov sagte, dass die Bank von Russland plant, bestehende Gesetze zu ändern. „Wir möchten uns verpflichten, Policen in einem Remote-Format in einer bedingungslosen Reihenfolge zu verkaufen. Es wird nicht die Wahl einer Versicherungsgesellschaft sein, sondern eine Pflicht “, sagte der Beamte.


upd2


Ein interessanter Kommentar erschien in der geektimes VKontakte Gruppe :
Hmm, aber ich weiß, welche Fehler er dort gefangen hat. Letzteres war mit der doppelten Richtliniennummer in der Datenbank verknüpft. Und der erste war ein Fehler beim Senden von Daten an die PCA (absichtlich aus Großbritannien).

Source: https://habr.com/ru/post/de394437/

More articles:


All Articles