Mi a teendő, ha nincs adat a PCA adatbázisban? Elektronikus OSAGO kötvény: a regisztráció finomságai, bővítése és hibajavítása A szerződő dokumentumának hibás típusa.
A szerződéstervezet állapotának betöltésére vonatkozó kérelem feldolgozási állapotának lekéréséhez az e-OSAGO CIS SC a rendszer ProjectPolicyService-jára hivatkozik, a kéréshez a getSetStatusResult metódust, a StatusPolicyEOSAGOStatusRequest.xsd sémát használja.
A megadott sémának megfelelő kérés összetételét a jelen kézikönyv 3. függeléke "Az interakciós formátumok specifikációja" tartalmazza.
Az e-OSAGO szerződéstervezet állapotának feltöltésére irányuló kérelem feldolgozási állapotának kérésekor a következő szempontokat kell figyelembe venni:
5.8.1. Az e-OSAGO-szerződéstervezet feltöltésére irányuló kérelem feldolgozásának állapotára vonatkozó kérelem egy bejegyzésazonosítót tartalmaz az e-OSAGO-szerződéstervezet státusz-hozzárendelése iránti kérelem sikeres feltöltése után kialakult, a szerződéstervezetek állapotának feldolgozására szolgáló sorban. a Rendszerbe (a jelen kézikönyv 5.7. pontja szerint).
5.8.2. Amikor az e-OSAGO szerződéstervezethez a „Megszakítva” állapot kerül elküldésre, és ha az e-OSAGO szerződéstervezet állapotának betöltésére vonatkozó kérés megfelel az FLC megállapított szabályainak, az „Elektronikus szabályzat” alrendszer választ generál a IC értesítéssel a státusz sikeres hozzárendeléséről az e-OSAGO megállapodás tervezetéhez.
5.8.3. Az SC válaszüzenet a StatusPolicyEOSAGOStatusResponse.xsd séma szerint jön létre, amelynek összetételét a jelen kézikönyv 3. függeléke „Az interakciós formátumok specifikációja” tartalmazza.
5.8.4. Az e-OSAGO szerződéstervezet „Aktív” státuszú elküldésekor és a szerződéstervezet állapotának rendszerbe történő feltöltésére irányuló kérelem sikeres feldolgozása esetén az Elektronikus Szabályzat alrendszer kérést küld e tervezet adatainak feltöltésére. megállapodás a DMDBM-mel a CMTPL DMDBM szerződéseinek/veszteségeinek letöltési szolgáltatásán keresztül.
5.8.5. Miután megkapta a DMDSS-től az e-OSAGO szerződés feldolgozási állapotára vonatkozó választ, a rendszer választ generál az IC számára, amely tartalmazza az összes információt az e-OSAGO megállapodás DMDSS-ben történő feldolgozásának eredményéről.
5.8.6. A szerződés DMDBM-ben történő sikeres feldolgozása esetén az „Elektronikus szabályzat” alrendszer választ generál az IC-től az „Aktív” állapot sikeres hozzárendeléséről szóló üzenettel az e-OSAGO szerződéstervezethez.
5.8.7. Abban az esetben, ha az e-OSAGO megállapodás nem ment át az FLC DMDBM ellenőrzésein, és nem került mentésre a DMDBM-ben, akkor a megfelelő e-OSAGO megállapodás tervezet szerint az Elektronikus Házirend alrendszer egy választ generál az IC-től egy üzenet, hogy az „Érvényes” állapot nincs hozzárendelve (az IsStatusAssign címkében false értéket ad vissza), valamint a DKBM hibalistája.
5.8.8. Ha a kérés feldolgozása során hibák lépnek fel, a rendszer választ generál az SC-től a kérés érvényesítésében azonosított hibák listájával, amelyet az SC válaszüzenet ErrorList címkéjében továbbít. A hibakódokat, azok leírását és a rendszer viselkedését a beérkezéskor a jelen dokumentum 1. függeléke, „Érvényesítési hibák” tartalmazza.
5.8.9. A kérés DKBM-ben történő feldolgozása során fellépő érvényesítési hibák a CK válaszüzenet ErorrDKBMList címkéjében vannak felsorolva. Az ilyen hibák kódjait és leírását az „Alrendszer-szerződések és a KBM AIS RSA üzemeltetői kézikönyve” című dokumentum tartalmazza.
5.8.10. A kérések feldolgozási státuszainak listája a jelen dokumentum 2. függelékében, „Kérés állapotok” található.
Kérjen szabad szobák számát az e-OSAGO szerződéstervezetekhez
A szerződéstervezetekhez tartozó ingyenes számok kérésének generálásához az e-OSAGO CIS SC meghívja a ProjectPolicyCountService szolgáltatást, a getFreeNumbers metódust, a NumberFreeRequest.xsd sémát használja a kéréshez.
Az e-OSAGO szerződéstervezetekhez rendelkezésre álló IC-számok számára vonatkozó kérés elküldésekor a következő szempontokat kell figyelembe venni:
5.9.1. Az e-OSAGO-megállapodástervezetek kialakításához rendelkezésre álló e-OSAGO-megállapodás-tervezetek számának korlátját a PCA-ban allokálja, és az e-OSAGO DB megfelelő táblázatába a PCA-adminisztrátor írja be az időszak elején minden egyes IC-re. .
5.9.2. A rendszer egy belső algoritmust biztosít az egyes IC-k szabad számainak kiszámításához, amely abból áll, hogy meghatározza az időszak eleji e-OSAGO IC szerződéstervezetek számának határa és a felhasznált e-OSAGO IC szerződések száma közötti különbséget. -OSAGO megállapodások minden egyes IC-hez.
5.9.3. Ha a szerződéstervezetet sikeresen elmenti a Rendszerbe, eggyel nő az e-OSAGO szerződéstervezet letöltésére kérelmet küldő biztosító használt számainak száma.
5.9.4. Ha az e-OSAGO szerződéstervezethez a „Megszakítva” állapotot rendeli, a használt SC-számok száma eggyel csökken.
5.9.5. Az ingyenes IC-számok számának kérésére adott válasz a NumberFreeResponse.xsd séma szerint jön létre, amelynek összetételét a jelen kézikönyv 3. függeléke „Az interakciós formátumok specifikációja” tartalmazza, és tartalmazza a szabad számok számát e. -OSAGO megállapodások a kérés időpontjában a kérelmet küldő IC számára.
5.9.6. A rendszer nem biztosítja a korábban az e-OSAGO szerződéstervezetekhez hozzárendelt számok újrafelhasználásának lehetőségét.
Kérjen egy listát az e-OSAGO szerződéstervezetek számáról
Az olyan e-OSAGO szerződéstervezetek listájára vonatkozó kérés generálásához, amelyekhez korábban nem rendelték hozzá a megfelelő állapotot, a CIS SK meghívja a ProjectPolicyListService szolgáltatást, a getList metódust, a ListPolicyEOSAGORequest.xsd sémát használja a kérelemhez.
A kérés összetételét jelen kézikönyv 3. függeléke „Az interakciós formátumok specifikációja” tartalmazza.
A státusz nélküli e-OSAGO szerződéstervezetek számlistájának kérésekor a következő szempontokat kell figyelembe venni:
5.10.1. A kérelem feldolgozása után az „Elektronikus szabályzat” alrendszer generál egy IC választ, amely tartalmazza azon e-OSAGO szerződéstervezetek számát, amelyek a kérés időpontjában nem „Érvényes” vagy „Törölve” állapotúak, és amelyeket korábban feltöltöttek. a kérelmet küldő IC.
5.10.2. Az NC válaszüzenete a ListPolicyEOSAGOResponse.xsd séma szerint jön létre, amelynek összetételét a jelen kézikönyv 3. függeléke "Az interakciós formátumok specifikációja" tartalmazza.
Tárgy azonosítás
A Rendszerben lévő objektumok azonosításának szabályait a 4. táblázat tartalmazza.
4. táblázat Az objektumok azonosításának szabályai
| Egy tárgy | Azonosító adatok | XML elemek |
| Megállapodás tervezete e-OSAGO | SC kód + SC megállapodás azonosító | Biztosítóazonosító + DraftPolicyID |
| Alany magánszemély (biztosító, járműtulajdonos) | HASH (teljes név + születési idő) + Bizonylat típusa + Iratsorozat + Bizonylatszám | PersonNameBirthHash + DocPerson + Sorozat + szám |
| Tárgy személy - LDU | HASH (teljes név + születési dátum) + VU sorozat + VU szám + dokumentum típusa | PersonNameBirthHash + Sorozat + szám + (DocPerson=20) |
| Alany jogi személy (biztosító és járműtulajdonos) | Alanyok számára - az Orosz Föderáció lakosai: "TIN" Alanyok számára - nem az Orosz Föderáció rezidensei: "Teljes név" (a regisztrációs bizonyítvány szerint (nyílt, nem kivonatolt formában) | Az Orosz Föderáció lakosai számára: INN Az Orosz Föderáció nem rezidensei számára: OrgName |
| Tárgy dokumentum | Dokumentumtípus + Dokumentumsorozat + Dokumentumszám | DocPerson + sorozat + szám |
| Jármű | A jármű azonosítása a "Gépjármű regisztrációs országa" mező értékének az alábbi módszerek egyikének mezőivel való kombinálásával történik: 1) Az azonosítót az alábbi adatok valamelyikének vagy ezek kombinációjának értéke határozza meg (ha több kitöltve):
| CountryCar 1) VIN Karosszériaszám Alvázszám 2) Rendszám |
Ellenőrzések folyamatban
A műszaki ellenőrzéseket akkor hajtják végre, amikor az "Elektronikus házirend" alrendszer kérést kap, amikor az xsd-sémáknak való megfelelőségét ellenőrizték. A rendszer xsd-sémáinak összetételét a jelen kézikönyv 3. függeléke "Az interakciós formátumok specifikációja" tartalmazza.
A benyújtott kérelmek xsd sémáknak való megfelelés kezdeti érvényesítésének elvégzése után a beküldött kérelmek logikai ellenőrzése történik, beleértve a kérés attribútumok kitöltésének ellenőrzését az egyéb attribútumok értékétől függően.
Az ellenőrzés logikájának megfelelően először a szülőelemekre történik az ellenőrzés, majd ha van szülőelem, akkor annak utód elemeire, tehát ha a szülőelem a tulajdonságokban opcionálisra van állítva, annak pedig kötelező. gyermekek, ha a szülő elem nem szerepel a fájlban, az ellenőrzés sikeresnek minősül.
A rendszer megvalósítja az elvégzett ellenőrzések beállításainak letiltását a PCA kezdeményezésére, beleértve az "Electronic Policy" alrendszert, amely lehetővé teszi az FLC ellenőrzések átfogó letiltását az e-OSAGO megállapodás tervezetének betöltésekor.
Ha az ellenőrzés le van tiltva, az ellenőrzés továbbra is megtörténik, de ha ezen az ellenőrzésen hiba érkezik, az e-OSAGO szerződés tervezete továbbra is mentésre kerül az Elektronikus Házirend alrendszer adatbázisába. Az állapotkérésre válaszul az SC üzenetet kap arról, hogy a szerződéstervezetet elmentették-e az adatbázisba, valamint az érvényesítési hibák listáját.
Az érvényesítési hibák teljes listája, valamint az ellenőrzések letiltása esetén végrehajtott rendszerműveletek az 1. függelékben, „Érvényesítési hibák” találhatók. A 2. függelék „A kérelmek állapota” tartalmazza az „Elektronikus szabályzat” alrendszerre vonatkozó kérések állapotainak listáját.
5. táblázat Az alany - a biztosított, a jármű tulajdonosa - adatainak ellenőrzésére vonatkozó kérelem (InsurerOwnerRequest.xsd)
| szülő elem | logikai név | Logikai ellenőrzés | |
| InsurerOwnerRequest | InsurerOwnerRequestValue | Az alany (biztosított/a jármű tulajdonosa) adatainak ellenőrzése | Kötelező kitölteni. |
| InsurerOwnerRequestValue | Biztosítóazonosító | ||
| PhysicalPersonInfoRequest | Egyedi adatok ellenőrzésre | A 2 elem közül az egyiket ki kell tölteni. | |
| LegalPersonInfoRequest | A jogi személy adatai ellenőrzésre | ||
| DateRequest | Dátum+idő kérése | Kötelező kitölteni. | |
| PhysicalPersonInfoRequest | Ország | Országkód az OKSM-ben | Kötelező kitölteni. |
| SzemélyNameBirthHash | Hash teljes név + születési dátum | Kötelező kitölteni. | |
| PersonDocument | A személyazonosító okmány típusa, sorozata és száma | Kötelező kitölteni. | |
| CímRSACód | |||
| PersonDocument | DocPerson | Személyazonosító okmány típusa | Kötelező kitölteni. A „Dokumentumtípusok” könyvtár kódjainak való megfelelés ellenőrzése. |
| Sorozatszám | Dokumentumok sorozata | Ha rendelkezésre áll, ki kell tölteni. Kitöltéskor - ellenőrizze, hogy nincsenek-e érvénytelen karakterek. | |
| szám | dokumentum szám | ||
| LegalPersonInfoRequest | Ország | Országkód az OKSM-ben | Kötelező kitölteni. |
| Szervezeti azonosító | Teljes név (a regisztrációs bizonyítvány szerint) + TIN (az Orosz Föderáció lakosai számára) | Kötelező kitölteni. | |
| CímRSACód | Cím - kód az RSA-KLADR könyvtárból | Kötelező kitölteni. A KLADR-könyvtár kódjainak való megfelelés ellenőrzése | |
| Szervezeti azonosító | Rezidens | RF/nem RF jele | Kötelező kitölteni. |
| FOGADÓ | Jogi személy TIN-száma | Az Orosz Föderáció lakosai számára kötelező. | |
| Szervezetnév | A jogi személy teljes neve (a regisztrációs okirat szerint) | Kötelező kitölteni. |
| szülő elem | Szülőelem attribútum | logikai név | Logikai ellenőrzés |
| DriverRequest | DriverRequestValue | LDU adatok ellenőrzése | Kötelező kitölteni. |
| DriverRequestValue | Biztosítóazonosító | Biztosító társasági azonosító | Kötelező kitölteni. A „Biztosítási társaságok” címtár kódjainak való megfelelés ellenőrzése. Ellenőrizze, hogy megfelel-e az üzenet fejlécében megadott SK azonosító. |
| DriverInfoRequest | LDU adatok ellenőrzésre | Kötelező kitölteni. | |
| DateRequest | Dátum+idő kérése | Kötelező kitölteni. | |
| DriverInfoRequest | |||
| SzemélyNameBirthHash | Hash teljes név + születési dátum | Kötelező kitölteni. | |
| DriverDocument | A jogosítvány sorozata és száma | Kötelező kitölteni. | |
| KategóriákVezetői engedély | Engedélyezett járműkategóriák vezetői engedéllyel | ||
| DriverDocDate | Az első vezetői engedély kiállításának dátuma | Kötelező kitölteni. Ennek a mezőnek az érvényesítése legfeljebb egy éves pontossággal történik. | |
| DriverDocument | Sorozatszám | Dokumentumok sorozata | Ha rendelkezésre áll, ki kell tölteni. Kitöltéskor - ellenőrizze, hogy nincsenek-e érvénytelen karakterek. |
| szám | dokumentum szám | Kötelező kitölteni. Ellenőrizze az érvénytelen karaktereket. | |
| KategóriákVezetői engedély | CatDriver License | Járműkategória a WU szerint | Kötelező kitölteni. Fel van tüntetve a járműkategória kódja a „Modell módosítások” kézikönyvben. Az ellenőrzés le van tiltva a DiKBM megfelelő változatának megvalósításáig. |
| szülő elem | Szülőelem attribútum | logikai név | Logikai ellenőrzés |
| TSRequest | TSRequestValue | A jármű adatainak ellenőrzése | Kötelező kitölteni. |
| TSRequestValue | Biztosítóazonosító | Biztosító társasági azonosító | Kötelező kitölteni. A „Biztosítási társaságok” címtár kódjainak való megfelelés ellenőrzése. Ellenőrizze, hogy megfelel-e az üzenet fejlécében megadott SK azonosító. |
| TSIinfoRequest | A jármű adatai ellenőrzésre | Kötelező kitölteni. | |
| DateRequest | Dátum+idő kérése | Kötelező kitölteni. | |
| TSIinfoRequest | vidéki autó | A jármű regisztrációs országa | Kötelező kitölteni. Ellenőrizze a „0” és „1” értékek betartását (1 - RF; 0 - nem RF) |
| CarIdent | Járműazonosítók | Kötelező kitölteni. | |
| MarkModelCarRSACode | Márkamodell kódja a PCA kézikönyvből | Kötelező kitölteni. Ellenőrizze, hogy megfelelnek-e az értékek a "Modell módosításai" című kézikönyvben. Ha a címtár nem tartalmazza a kívánt modellt, akkor a címjegyzék kódját kell továbbítani, amelynek neve "Egyéb modell" szavakkal kezdődik és amely megfelel a szükséges járműkategóriának és típusnak. | |
| évszám | Kibocsátási év | Feltöltéshez szükséges, kivéve a külföldön bejegyzett járműveket. | |
| típusú autó | Jármű típus | Feltöltéshez szükséges, kivéve a külföldön bejegyzett járműveket. A jármű típuskódja a „Modell módosítások” kézikönyvben található. | |
| macskakocsi | Jármű kategória | Kötelező kitölteni, ha a járműkategória kódját az RSA „Modell módosítások” referenciakönyvében töltik ki, kivéve a külföldön nyilvántartásba vett járműveket. Fel van tüntetve a járműkategória kódja a „Modell módosítások” kézikönyvben. Ha a jármű kategóriakódja nincs kitöltve az RSA „Modell módosítások” referenciakönyvében, akkor a CatCar címke nincs kitöltve a járműellenőrzésben. | |
| DocumentCar | TS dokumentumtípus | Feltöltéshez szükséges, kivéve a külföldön bejegyzett járműveket. A „Dokumentumtípusok” könyvtár kódjainak való megfelelés ellenőrzése. | |
| DocCarSerial | TS dokumentumsorozat | ||
| DocCarNumber | TS dokumentumszám | Feltöltéshez szükséges, kivéve a külföldön bejegyzett járműveket. Ellenőrizze az érvénytelen karaktereket. | |
| DocumentCarDate | A jármű okmányának kiállításának dátuma | Feltöltéshez szükséges, kivéve a külföldön bejegyzett járműveket. Az ellenőrzés le van tiltva a DiKBM megfelelő változatának megvalósításáig. | |
| EngCap | Motorteljesítmény B kategóriához, LE | CatCar = "B" esetén kötelező, kivéve a külföldön bejegyzett járműveket. | |
| MaxMass | Megengedett legnagyobb tömeg kilogrammban a C kategória esetében | CatCar = "C" esetén kötelező, kivéve a külföldön bejegyzett járműveket. | |
| UnloadenMass | Üres tömeg kilogrammban a C kategória esetében | CatCar = "C" esetén kötelező, kivéve a külföldön bejegyzett járműveket. Az ellenőrzés le van tiltva a DiKBM megfelelő változatának megvalósításáig. | |
| PasQuant | Utasülések száma a D kategóriában | CatCar = "D" esetén kötelező, kivéve a külföldön bejegyzett járműveket. | |
| CarIdent | rendszámtábla | Állapot. szoba | A 4 elem egyikét ki kell tölteni. Ellenőrizze az érvénytelen karaktereket. A VIN/BodyNumber/ChassisNumber címkék kitöltésekor ellenőrzi, hogy a LicensePlate címke (állami szám) nincs-e kitöltve. A LicensePlate címke kitöltésekor ellenőrzi, hogy más járműazonosítók nincsenek-e kitöltve. A jármű keresése és ellenőrzése a DKBM alrendszerben a járműazonosítók (meghatározott számú azonosító és értékük szerint) teljes egyezése alapján történik. Az állapotszám ellenőrzése a jármű egyetlen azonosítója, az állapotszámok között történik. |
| VIN | VIN | ||
| BodyNumber | testszám | ||
| Alvázszám | Alvázszám |
A fő probléma, amellyel az autósok szembesülnek, amikor online OSAGO-t próbálnak kiállítani egy biztosító társaság honlapján, egy hiba, amely akkor fordul elő, hogy az információ " nem ment át a teszten az AIS RSA-ban"(ő is -" Nem érkezett visszaigazolás a központosított PCA-rendszerektől”). Ez azt jelenti, hogy a valahol beírt adatok (legalább némi vesszőben, legalább egy számjegyben) eltérnek a Biztosítók Szövetségének adatbázisában rögzítettektől.
Ennek három oka lehet:
- Valahol hibát követett el, ellenőrizze újra az összes mezőt, hogy nincs-e elírás. Egyes biztosítótársaságok weboldalai (például Rosgosstrakh) sárgával kiemelik azokat a mezőket, amelyek nem feleltek meg a teszten, vagy közvetlenül felsorolják a hibák helyét (például HOSKA). Mások (például RESO) nem határozzák meg, hogy pontosan mi nem tetszett a rendszernek.
Mellesleg ezért jobb, ha először „elkapja” a hibákat egy ilyen oldalon, még akkor is, ha nem ettől a társaságtól tervezi az OSAGO-t vásárolni, majd regisztrálja azt a biztosító honlapján. Már csak azért is, mert a CGS weboldalát kényelmesebbé tették, és kiemeli a hibákat (egyes monitorokon az alacsony kontrasztú sárga háttérvilágítás rosszul látható, ebben az esetben próbáljon „alulról” nézni a képernyőt, így a színek kontrasztosabbak lesznek, és látni fogja, hol a hiba):
- Talán eltérések vannak a modell helyesírásában, vagy a címében, vagy más paraméterben a valóságban és a TCP-ben. Ezért feltétlenül ellenőrizze az adatokat a PTS-nél és a COP-nál (Regisztrációs tanúsítvány - egy kártya, amelyet magával visz).
És még jobb az összes mezőt a tavalyi szabályzat szerint ellenőrizni - ezek az adatok "hazudnak" az AIS RSA-ban. Kérjük, vegye figyelembe, hogy ha választhat a TCP-szám és a COP-szám között, akkor meg kell írnia azt, amit az utolsó OSAGO szabályzat 2. pontjában jeleztek.
- A hibát nem Ön követhette el, hanem a biztosító ügynöke vagy alkalmazottja, amikor legutóbb OSAGO-t állított ki. Itt nem lehet mit tenni, ki kell deríteni, hogy pontosan hol van az eltérés és miből áll. Ha van ideje és kedve az OSAGO-t az interneten keresztül kibocsátani, akkor írja meg az oldalon található egy (és lehetőleg több) biztosítótársaság technikai támogatásának, hogy meg akarja vásárolni az OSAGO-t. Általában 1-2 napon belül válaszolnak a hiba leírásával.
Ezenkívül előfordulhat, hogy a probléma nem magában a gépen lévő adatokban van, hanem harmadik féltől származó dokumentumokban:
- hogy az Ön számára kiállított diagnosztikai vizsgálati kártya bekerült az EAISTO-ba, ellenőrizze az adatokat ezzel az adatbázissal.
- Ellenőrizze regisztrációs címét. Ebben az esetben, ha az új regisztrációs tanúsítvány száma nem megy, próbálja meg feltüntetni a TCP-t (és fordítva).
- új! Az oldalon található megjegyzéseknek és felhasználói véleményeknek köszönhetően felfedeztem egy másik gyakori okot a „PTS / Certificate” hibának. Nem ritka, hogy a TCP mezőben az adatbázis tartalmazza a tanúsítvány számát vagy fordítva, vagyis összekeveredett a dokumentum típusa. Ezért próbálja meg kiválasztani a „jármű regisztrációs igazolása” dokumentumot, de tárcsázza a jármű számát. És fordítva. Sokat segít!
- új! Egyre több cég kínálja az eOSAGO-t, de az „újoncok” többsége csak megújítási módban teszi ezt. Vagyis csak meghosszabbíthatja a tavalyi kötvényüket, de nem lehet ennek a biztosításnak új ügyfele. Ha valamelyik társaságnál kötötték a tavalyi biztosítást, akkor mindenekelőtt próbálj meg náluk megújítani, mert csak az ő honlapjukon tudod automatikusan letölteni a tavalyi adatokat és ezzel kiküszöbölni a „PCA probléma” gyökerét.
Egyáltalán honnan jön ez a hiba? A tény az, hogy ha ügynökön keresztül vásárol kötvényt, az ügynök bármilyen információt bevihet az adatbázisba. Úgy tartják, hogy képzett alkalmazott. És amikor felmerült a biztosítás online értékesítésének kérdése, senki sem adhat lehetőséget a járművezetőknek, hogy maguk jelezzék a lóerőt és más fontos jellemzőket - különben mindenkinek azonnal 99 LE lesz! Ezért elvégeztük ezt az ellenőrzést – ez azt jelenti, hogy a bevitt adatok egybeesnek az AIS SAR adatbázis legfrissebb adataival. Más szóval, meg kell egyeznie azzal, amelyet az ügynök adta meg az előző kötvény megvásárlásakor.
De az ügynökök nem mindig tökéletesek, ráadásul a politika egy kis pontatlansága korábban nem igazán számított. Valamelyik ügynök például alapból 99 LE-t írt minden kisautóhoz, a pontos 95, 85 vagy 91 helyett - amúgy az ára ugyanaz. Vagy egy másik példa - az egyik biztosítótársaságban a belső programjukban a Hyundait, a másikban pedig a Hyundait szokás írni. Néhányan kerekítették a számokat, mások nem. És most a sofőrnek kell „kitalálnia”, hogyan rögzítették az összes adatot az utolsó biztosításban.
Mit lehet még tenni?
- Ha megérti, hogy a hiba a PCA adatbázisban van, és „kitalálta” a hibát, akkor újra megadhatja az adatokat hibával vagy elírással „mint az adatbázisban”. Ez az az eset, amikor az online kitöltési szolgáltatás lehetővé teszi tetszőleges adatok megadását, és nem a javasolt listából való választást (próbáljon meg különböző biztosítókat, mindenkinek más a „felülete”). Formálisan így téves adatokkal kötött biztosítási szerződést, de a legtöbb biztosító ezt megértéssel kezeli, még akkor is, ha biztosítási esemény bekövetkezik (legalábbis én tisztáztam ezt a kérdést a HOSKA SG képviselőjével, és biztosítottak, hogy elismerik megállapodást, de megkérik, hogy jöjjön el az irodába és újítsa meg a szerződést a naprakész adatokért). Ám annak érdekében, hogy 100%-ig biztos legyen a kötvény jogosságában, az e-OSAGO megvásárlása után bármikor felveheti a kapcsolatot biztosítója irodájával, és kérheti az adatok frissítését. A megkötött elektronikus OSAGO adatainak megváltoztatásának lehetőségét az értékesítési irodában tett személyes látogatás során a Rosgosstrakh képviselői megerősítették, hozzátéve, hogy a közeljövőben (2016-ban?) tervezik az adatok megváltoztatásának lehetőségét megvalósítani. az OSAGO e-irányelv interneten keresztül. Általánosságban elmondható, hogy a módszer nem 100% -ban helyes, de a gyakorlatban valószínűleg nem lesz probléma.
- Ha jelenlegi OSAGO-biztosítása még nem járt le, akkor felveheti a kapcsolatot azzal a társasággal, ahol jelenleg biztosított, és kérheti az adatok frissítését az adatok helyes módosításával. Lehetőleg ellenőrizze betűre mindazt, amit az irodavezető beír a számítógépbe. Ezt követően várjunk pár napot, amíg a PCA adatbázisban lévő adatok frissülnek, és próbáljuk újra! Ráadásul egyes biztosítók akár telefonon is készen állnak az adatok kétszeri ellenőrzésére, nem nagyon derül ki, hogyan azonosítják az ügyfelet. De például az oldal egyik olvasója, Vadim Szamarából azt mondta, hogy egyszerűen sikerült frissítenie a PCA adatait telefonon a ZHASO biztosítónál, amelyben biztosított volt. Ez azonban sokkal helyesebb módszer, és nem mindig működik. Példa erre Vitalij Volzsszkij városának áttekintésében, amelyet levélben küldött nekem:
Egy hónappal a kötvény lejárta előtt kezdtem el lyukasztani, megjelentek a hibák, utána egy utca nyelvtani hibákkal, akkor az autó nevében nem jók a betűk (van egy Suzuki SX4-em a dokumentumok szerint, de az SX-4 volt bekerült az adatbázisba). Elmentem a központi irodába Volgográdba, mindent kijavítottam, de még mindig nem tudtam megszerezni az eOSAGO-t, mert. az oldal fizetés előtt MarkModelCarRsaCode hibát adott. Ez a hiba a hírhedt „-” problémája az autó márkájában, de mint kiderült, az SX4 az összes biztosító összes bázisán átmegy, és csak a Zetta Insurance LLC (személyesen láttam a monitoron ) csak az SX-4-et választja ki. Így egy hónap alatt nem tudtam minden problémát megoldani, de miután az irodalátogatással kikerestem adataimat (kivéve az autó márkáját), valahogy felkészültem az egy év múlva következő biztosításra.
A tippeket frissítjük.
Szeretném hallani a véleményét a megjegyzésekben.
Szeretnél tesztet tenni a cikk anyagairól a cikk elolvasása után?
IgenNem
Igazi ajándék az autótulajdonosok számára, hogy otthonról el kell hagynunk egy autót! Azonban itt is időnként előfordulnak kellemetlen meglepetések: például amikor az OSAGO-ra online jelentkezik, az AIS RSA adatbázisával való ellenőrzés nem megy át. Megoldható-e egyedül is a probléma, vagy kötelező a biztosító személyes felkeresése?
A probléma okai
Ha az OSAGO kötvény online igénylésekor az AIS RSA ellenőrzése nem felel meg, az ok mindig ugyanaz - valahol adateltérés van. A lehető legegyszerűbb lehetőség az, hogy egyszerűen hibázott, amikor adatokat írt be a kötelező mezőkbe. Ilyenkor még egyszer ellenőrizzen mindent, ügyelve a szavak helyes írásmódjára.
Egyes biztosítók gondoskodtak elektronikus kötvényt kötni kívánó ügyfeleik kényelméről: a vitatott helyek kiemelésével bővítették a szolgáltatást. Ez nagyban leegyszerűsíti a hibák kijavításának folyamatát: csak próbáljon ki többféle lehetőséget – és biztosan megtalálja a megfelelőt!
A gépelési hibák mellett előfordulhat, hogy bizonyos információkat másképp írtál, mint legutóbb. Talán akkor információkat másolt a TCP-ről, és most a memóriából írt, vagy fordítva. Mindenesetre teljes azonosságot kell elérnie a tavaly benyújtott adatokkal. 
Az ideális megoldás, ha mindent átír a tavalyi szabályzatból, akkor biztosan átmegy a PCA teszten.
Mit kell tenni?
Rossz, ha nem te hibáztál, hanem annak a biztosítónak a munkatársa, aki segítségével az előző kötvényt elkészítették. Most ezt a hibát Önnek tulajdonítják, amíg ki nem javítja. Szóval mit kéne tenni? Ebben az esetben több lehetőség is van az eseményekre.
BIZTOSÍTÓK RÉGIÓBÓL! Rajtad a biztosítóknál vannak szűrők! Az ip megváltoztatása nem segít...
Nem tudok elektronikus OSAGO kötvényt kiadni, napokig piszkálhatod a gombokat a kötvény kiadásakor. Adja meg újra és újra az információkat, reggel, délután és este, akár éjszaka is fel tud kelni, de NEM ALKALMAZJA az elektronikus OSAGO-t! És ne is reménykedj.
2017.01.01-től kötelezővé tették az elektronikus OSAGO kötvény regisztrációját a biztosítók számára. Addig is mindent megtettek annak érdekében, hogy minél több pénzt kisakarjanak a biztosítottaktól.
Lehet, hogy nem hiszi el, de 2019 van, és valójában semmi sem változott. Az OSAGO online problémái továbbra is fennállnak.
A PCA-nál találtam egy listát azokról a biztosító szervezetekről, amelyek elektronikus dokumentumok formájában kötnek szerződéseket, de OSAGO kötvényt tőlük sem tudok online vásárolni.
A biztosítók frissített listája— 51 társaság.
E cégek egyike sem értékesít elektronikus OSAGO-t. Megújítani, igen lehetséges, vásárolni - nem!
Például:
VSK honlapja
A VSK-nál nem lehet online OSAGO kötvényt kiállítani, ha szerencséd van, átmegy a PCA adatbázisban, de ez a „kiválasztottaknak” szól, a legtöbb látni fogja.
És az IT fog forogni egy órát, kettőt és egy napot.
RESO-GARANCIA honlapján
Még a személyes fiók elindításával is egész gondjuk van, egy nappal később sikerült is.
De ha tovább megy is, töltse ki az összes mezőt az adatok megadásával, számolja ki a költséget, akkor kap egy számítási számot, el kell mentenie a számítást, mentéskor hibaüzenetet kap egy lejárt munkamenetben frissítenie kell az oldalt, és itt megtalálja a valódi okot.
Ez a hiba azt mondja az űrlap nincs beállítva az adatbázissal való együttműködésre. Csodálatos az egész. És megbízhat bennem, mint technikusban.
Rosgosstrakh honlapja
Az elektronikus OSAGO Rosgosstrakh nem működik. Itt váratlan hibaüzenetet kap, és ennyi!
A listáról az összes biztosítót átadhatja, de az eredmény 0 lesz.
A végén happy end lettem, ahogy mondani szokás. Vettem kötvényt, de nem neten, hanem a biztosító irodájában. Aztán, ahogy mondják, csak szerencsés.
Sokféleképpen kipróbáltam az OSAGO online jelentkezését!
Próbáltam barátokon keresztül jelentkezni, de még rajtuk keresztül is szükség volt további szolgáltatások kiadására + egy bizonyos összeg „szorongásra”. És megpróbáltam megújítani a kötvényt ugyanabban a cégben, amelyet vásároltam. OSTOBASÁG.
Ha csak ismeretségek és blat nélkül készítesz egy szabályzatot (nem hiszem, hogy magam írom), akkor napokat és heteket tölthetsz napi névsorolvasással. Egy dolgozó embernek NINCS ANNYI IDŐ. És ez teljes mértékben és teljes mértékben megmagyarázza, miért lehetetlen az OSAGO online kiadása.
Teljes a káosz, a szabályozó hatóságok nem csinálnak szart. Az ügyészség általában mindent "lepontozott". Korábban azt írták, hogy "az Ügyészség nagyszabású ellenőrzést folytat a biztosítóknál" és akkor mi van? Nem fontos! Üres! Bagel lyuk!
Minden ellenőrzésük annyi, hogy faxon küldik el a biztosítónak egy „Azt mondják, az OSAGO-t kiegészítő szolgáltatásokkal adják el” kérését, amelyre faxon is választ kapnak Igen, hogy gondolhatta ezt! A biztosítók azok, akik további szolgáltatásokat kérnek tőlünk.” Vicces! A könnyekig! De valójában ez így történik.
Ha minden másképp lett volna, próbavásárlást hajtottak volna végre, és ebben minden biztosító segített volna nekik, és egyenként százezres, sőt milliós rubel bírságot szabtak ki a biztosítókra.
Zárásként szeretném elmondani.
AZ EMBEREK SENKIBEN NEM BÍZNAK! Ingyenes LEHETETLEN OSAGO kötvény online kiadása 2019-ben! Az egyetlen hely, ahol online igényelhető az OSAGO, Moszkva és Szentpétervár, mivel ott a legdrágábbak a kötvények, és a régiók biztosítói oda küldik őket.
BIZTOSÍTÓK RÉGIÓBÓL! A biztosítók szűrőkkel rendelkeznek! Sem az ip megváltoztatása, sem a proxy használata nem segít, a szűrők a regisztráció helye szerint vannak beállítva.
A biztosítók nem csak kigúnyolnak minket, hanem szadista örömmel teszik. Ennek érdekében letiltották a bevitt adatok űrlapon való mentésének lehetőségét. Ha frissíti az oldalt, az összes megadott adat elveszik. Vagyis fél órát ülsz beírod a jogok, címek számait stb, a végén hibaüzenetet kapsz, frissíted az oldalt és itt van előtted egy tiszta űrlap. Adatai eltűntek.
Csak az INGOSSTRAKH honlapján, a számítás után azt írták, hogy "OSAGO kötvényt a legközelebbi irodában adhat ki". Használja ki a tanácsot, és ne vesztegessen időt, erőfeszítést és idegeket azzal, hogy online kötvényt igényel. Jelenleg csak a biztosító irodájában vásárolhat OSAGO kötvényt.
P.S. Ne felejtse el ellenőrizni a megvásárolt OSAGO szabályzatot a PCA adatbázisban, függetlenül attól, hogy hol vásárolta, az irodában vagy az interneten. A címünkre számos panasz érkezett a biztosítási alkuszok általi hamis kötvények értékesítésére.
