Содержание сообщений
При формировании сообщений используются справочники, содержание некоторых из них (типы документов, статусы запросов, типы страховых событий) приведены в Приложении А.В Приложении А приведены также ошибки от модуля регистрации запросов СМЭВ.
Информация при заполнении данных ТС, в частности "Код марки/модели ТС", до внедрения доработки ПО ДиКБМ в части использования справочников, берется из справочника «Марки-модели» АПК ИРЦ ОСАГО (Аппаратно-программный комплекс информационно-расчетного центра системы прямого урегулирования убытков), для доступа к которому необходимо пройти авторизацию на сайте РСА: www.autoins.ru и пройти по ссылке: http://autoins.ru/ru/Evro/pvu/strahovschiki/ais_pvu/index.wbp.
После внедрения доработки ПО ДиКБМ в части использования справочников для доступа к актуальной нормативно-справочной информации необходимо пройти авторизацию на сайте РСА: www.autoins.ru и пройти по ссылке http://www.autoins.ru/ru/closed/members/reference/.
Детальное описание xsd-схем приведено в документе «Спецификация форматов взаимодействия с веб-сервисами ДиКБМ».
Если СК не заполняет элемент типа данных integer, то СК не должна указывать незаполненный элемент в сообщении, поскольку сообщение в этом случае не пройдет валидацию на соответствующую xsd-схему.
1.9Импорт Договоров
1.9.1СК формирует пакет сведений о договорах для отправки на загрузку в Подсистемы ДиКБМ. Веб-сервис договоров/убытков обеспечивает прием пакетов договоров/убытков от учетных систем СК и отправку статусов обработки.
Для формирования запроса на загрузку договоров КИС СК вызывает веб-сервис policyLossService, операцию LoadPolicy, для запроса используется PolicyRequest.xsd.
Запрос содержит следующие данные:
PolicyTitle – идентификационные сведения рейса пакета договоров;
Policies – данные договоров, входящих в пакет.
Состав запроса, соответствующий схеме описания PolicyRequest.xsd,приведен в таблице 6.2. В графе «Родительский элемент» приведены комплексные (составные) элементы (элементы, содержащие другие элементы или атрибуты). Тип комплексного элемента - Complex type.
1.9.2При изменении или технической коррекции договора необходимо передавать все значимые поля договора (информация в ДиКБМ вносится из переданных данных, т.е. фактически, перезаписывается). Таким образом, если изменилось одно или несколько полей договора, то необходимо передавать значения всех полей (измененные и не измененные). Например,
если изменяется ограничение лиц, допущенных к управлению, с неограниченного на ограниченный, в новой версии необходимо указать DriversRestriction=true, и добавить в блоке Drivers информацию по лицам, допущенным к управлению
если изменяется договор с ограниченного на неограниченный, то в новой версии указывается DriversRestriction=false, а блок данных Drivers не передается.
1.9.3Информация об использовании версий договоров при формировании запросов следующая:
1.9.3.1Дата, указанная в поле ”DateRevision” комплексного элемента Policy, является Датой внесения изменений при PolicyHandle = CorrectError, ChangeObject и Recall.
Дата внесения изменений (DateRevision) не может быть равной или меньше Даты заключения Договора (DateCreate).
Дата внесения изменения (DateRevision) должна быть уникальной в рамках договора.
1.9.3.2Даты, указанные в полях “DateAgreementCreate” ”DateAgreementBeg” комплексного элемента Policy, являются датами заключения дополнительного соглашения и начала действия дополнительного соглашения и могут передаваться при PolicyHandle = ChangeObject при создании нового доп. соглашения или при PolicyHandle = CorrectError при корректировке данных дополнительного соглашения. Даты заключения дополнительного соглашения и начала действия дополнительного соглашения, как правило, будут совпадать, но могут быть и исключения.
Для загрузки нового договора необходимо передать данные: PolicyHandle=New; для идентификатора договора внутри СК, например, PolicyID = 1; для идентификатора версии Договора внутри СК– AddAgreementID = 0; DateRevision не передается.
1.9.3.3Для загрузки, например, дополнительного соглашения № 1 к договору необходимо передать данные: PolicyHandle = ChangeObject; для идентификатора договора внутри СК– PolicyID = 1; для идентификатора версии Договора внутри СКAddAgreementID = 1; дата заключения дополнительного соглашения, например DateAgreementCreate = 01.01.2012 00:00:00; дата начала действия дополнительного соглашения, например, DateAgreementBeg = 01.01.2012 00:00:00; дата ввода изменений в КИС СК DateRevision = 02.01.201215:00:00.
1.9.3.4Для загрузки, например, дополнительного соглашения № 2 к договору необходимо передать данные: PolicyHandle = ChangeObject; для идентификатора договора внутри СК– PolicyID = 1; для идентификатора версии Договора внутри СК – AddAgreementID = 2; дата заключения дополнительного соглашения, например DateAgreementCreate = 03.01.2012 15:00:00; дата начала действия дополнительного соглашения, например, DateAgreementBeg = 05.01.2012 00:00:00; дата ввода изменений в КИС СК DateRevision = 03.01.2012 16:00:00.
1.9.3.5Для отзыва договора необходимо передать данные: PolicyHandle = Recall; для идентификатора договора внутри СК, например, PolicyID = 1; AddAgreementID = 0; DateRevision = дата отзыва.
Договор отзывается целиком, включая все его версии. Промежуточные версии отзываются операцией PolicyHandle =RecallAddAgr.
После отзыва договора при повторной загрузке требуется ввести информацию по договору и всем его дополнительным соглашениям. При отзыве договора в ДиКБМ его данные не удаляются, а лишь отмечаются как отозванные.
1.9.3.6Для отзыва дополнительного соглашения договора необходимо передать данные: PolicyHandle = RecallAddAgr; для идентификатора договора внутри СК, например, PolicyID = 1; AddAgreementID = 1 (не должно быть 0); DateRevision = дата отзыва.
Отзывается указанная в элементе AddAgreementID версия договора, при этом дата окончания предыдущей версии договора устанавливается в соответствии с датой окончания отзываемой версии договора.
При отзыве версии договора в ДиКБМ ее данные не удаляются, а лишь отмечаются как отозванные.
Отозвать дополнительные соглашения можно в обратной последовательности, начиная с последнего дополнительного соглашения, например: вначале отзывается последнее дополнительное соглашение № 3, затем - № 2, затем - № 1.
Для убытка, который ссылался на изменяемую версию договора, устанавливается связь на версию договора, актуальную на Дату ДТП.
1.9.3.7Для корректировки договора необходимо передать данные: PolicyHandle = CorrectError; для идентификатора договора внутри СК, например, PolicyID = 1; AddAgreementID = 0; DateRevision = дата внесения изменений.
1.9.3.8Для корректировки, например, дополнительного соглашения № 1 к договору необходимо передать данные: PolicyHandle = CorrectError; PolicyID = 1; AddAgreementID = 1; DateRevision = дата внесения изменений.
Передаются также данные по БСО: PolicySerialKey, PolicyNumberKey – для корректируемой версии дополнительного соглашения № 1.
Корректировка может изменять номер/серию БСО только последнего дополнительного соглашения. В этом случае, вместе с PolicySerialKey и PolicyNumberKey последнего дополнительного соглашения № 1 передаются данные: PolicySerialChange, PolicyNumberChange – новые номер/серия БСО для корректируемого дополнительного соглашения № 1.
Передаваемая дата начала действия дополнительного соглашения DateAgreementBeg должна соответствовать дате начала действия дополнительного соглашения № 1.
1.9.3.9Для корректировки, например, дополнительного соглашения № 2 к договору необходимо передать данные: PolicyHandle = CorrectError; PolicyID = 1; AddAgreementID = 2; DateRevision = дата внесения изменений.
Передаются также данные по БСО: PolicySerialKey, PolicyNumberKey – для корректируемой версии дополнительного соглашения № 2.
Корректировка может изменять номер/серию БСО только последнего дополнительного соглашения. В этом случае, вместе с PolicySerialKey и PolicyNumberKey последнего дополнительного соглашения № 2 передаются данные: PolicySerialChange, PolicyNumberChange – новые номер/серия БСО для корректируемого дополнительного соглашения № 2.
Передаваемая дата начала действия дополнительного соглашения DateAgreementBeg должна соответствовать дате начала действия дополнительного соглашения № 2.
1.9.3.10Начиная с версии xsd 1.2, допускается отправка нескольких дополнительных соглашений к договору с совпадающей Датой начала действия дополнительного соглашения (DateAgreementBeg), а также с Датой начала действия дополнительного соглашения, совпадающей с Датой начала действия основного договора.
В случае если у договора есть несколько дополнительных соглашений с совпадающей Датой начала действия дополнительного соглашения, наиболее актуальным из дополнительных соглашений ДиКБМ будет считать Дополнительное соглашение с наиболее поздней Датой ввода изменений оператора (DateRevision). При этом следует учесть, что при корректировке Дополнительного соглашения новая Дата ввода изменений оператором для корректируемого дополнительного соглашения (DateRevision) при выстраивании версий договора учтена не будет. При выстраивании версий дополнительных соглашений договора с совпадающими Датами начала действия дополнительного соглашения учитываются только Даты ввода изменений оператором (DateRevision), полученные при создании дополнительного соглашения (операция PolicyHandle=ChangeObject)
Для корректировки последовательности дополнительных соглашений с совпадающей Датой начала действия дополнительных соглашений (DateAgreementBeg) некорректные дополнительные соглашения следует отзывать и вносить заново, убедившись, что DateRevision установлены в последовательности, соответствующей последовательности дополнительных соглашений.
Пример 1:
Страхователь заключил договор 01.06.2013 сроком действия 1 год, дата начала действия договора 15.06.2013.
05.06.2013 Страхователь обратился в СК с целью внесения изменений в договор (изменение списка ЛДУ). СК заключает Дополнительное соглашение1
07.06.2013 Страхователь обратился в СК с целью повторного внесения изменений в договор (повторное изменение списка ЛДУ). СК заключает Дополнительное соглашение2.
При заключении договора СК указывает:
PolicyHandle=New
AddAgreementID= 0
DateCreate=01.06.2013
DateActionBeg=15.06.2013
DateActionEnd=14.06.2014
Призаключении Дополнительного соглашения1:
PolicyHandle=ChangeObject
AddAgreementID= Идентификатор Дополнительного соглашения1
DateCreate=01.06.2013
DateActionBeg=15.06.2013
DateActionEnd=14.06.2014
DateAgreementCreate=05.06.2013
DateAgreementBeg=15.06.2013
DateRevision=05.06.2013
Призаключении Дополнительного соглашения2:
PolicyHandle=ChangeObject
AddAgreementID=Идентификатор Дополнительного соглашения2
DateCreate=01.06.2013
DateActionBeg=15.06.2013
DateActionEnd=14.06.2014
DateAgreementCreate=07.06.2013
DateAgreementBeg=15.06.2013
DateRevision=07.06.2013
В этом примере в истории договора наиболее актуальным будет считаться Дополнительное соглашение 2, т.к. несмотря на то, что Даты начала действия дополнительных соглашений совпадают, DateRevision Дополнительного соглашения 2 наиболее актуальная.
Пример 2.
Ситуация аналогична описанной в Примере 1, за исключением того, что 10.06.2013 при аудите представитель СК замечает, что в Дополнительном соглашении 1 была допущена техническая ошибка ввода.
Регистрация договора, Дополнительного соглашения 1 и Дополнительного соглашения 2 происходит аналогично Примеру 1
При корректировке Дополнительного соглашения1 СК указывает:
PolicyHandle=CorrectError
AddAgreementID=Идентификатор Дополнительного соглашения1
DateCreate=01.06.2013
DateActionBeg=15.06.2013
DateActionEnd=14.06.2014
DateAgreementCreate=05.06.2013
DateAgreementBeg=15.06.2013
DateRevision=10.06.2013
Для этого примера в истории договора наиболее актуальным будет являться Дополнительное соглашение 2, несмотря на то, что Дополнительное соглашение 1 было откорректировано с более поздней Датой ввода изменения оператором (DateRevision). Данная ситуация возникла, т.к. для выстраивания версий договоров совпадающими Датами начала действия дополнительных соглашений (DateAgreementBeg) используются только DateRevision, полученные при проведении операции c PolicyHandle=ChangeObject.
1.9.3.11Начиная с версии xsd 1.2, допускается корректировка Даты начала действия договора с использованием элемента DateActionBegChange.
Корректировка Даты начала действия для договоров, для которых в ДиКБМ уже загружены дополнительные соглашения, не допускается.
Корректировка Даты начала действия для договоров, для которых в ДиКБМ уже загружены убытки, не допускается.
1.9.3.12Операции по изменению данных договора представлены в таблице 6.1.
Таблица 6.1
Тип
|
Пример операции
|
ChangeObject /
CorrectError
|
Поле
|
Обязательность заполнения поля для операции
|
Заполнение поля старым/новым значением
|
PolicyType
|
Изменена дата окончания действия договора
|
ChangeObject
|
DateActionEnd
|
Да
|
Старое
|
Исправлена ошибка в дате окончания действия договора
|
CorrectError
|
DateActionEnd
|
Да
|
Старое
|
DateActionEndChange
|
Да (для AddAgreementID = 0)
|
Новое
|
Изменена дата начала действия договора
|
ChangeObject
|
DateActionBeg
|
Да
|
Старое
|
Исправлена ошибка в дате начала действия договора
|
CorrectError
|
DateActionBeg
|
Да
|
Старое
|
DateActionBegChange
|
Да (для AddAgreementID = 0)
|
Новое
|
Изменена дата начала действия доп.соглашения к договору
|
ChangeObject
|
DateAgreementBeg
|
Да
|
Старое
|
DateAgreementBegChange
|
Да
|
Новое
|
Исправлена ошибка в дате начала действия доп.соглашения к договору
|
CorrectError
|
DateAgreementBeg
|
Да
|
Старое
|
DateAgreementBegChange
|
Да
|
Новое
|
Изменена дата заключения доп.соглашения к договору
|
ChangeObject
|
DateAgreementCreateChange
|
Да
|
Старое
|
DateAgreementCreateChange
|
Да
|
Новое
|
Исправлена ошибка в дате заключениядоп.соглашения к договору
|
CorrectError
|
DateAgreementCreateChange
|
Да
|
Старое
|
DateAgreementCreateChange
|
Да
|
Новое
|
Изменение серии БСО
|
ChangeObject
|
PolicySerialKey
|
Да
|
Старое
|
PolicySerialChange
|
Да
|
Новое
|
Исправление опечатки в Серии БСО
|
CorrectError
|
PolicySerialKey
|
Да
|
Старое
|
PolicySerialChange
|
Да
|
Новое
|
Изменение номера БСО
|
ChangeObject
|
PolicyNumberKey
|
Да
|
Старое
|
PolicyNumberChange
|
Да
|
Новое
|
Исправление опечатки в номере БСО
|
CorrectError
|
PolicyNumberKey
|
Да
|
Старое
|
PolicyNumberChange
|
Да
|
Новое
|
|
