Получены ошибки из АИС ОСАГО при попытке сохранения проекта договора (ISN=14052964100) requestId=00000000-0000-0000-1af4-82cd5e83f2df : {«code»:«12003032»,«description»:«Дата выдачи бланка страхователю должна быть в промежутке (включительно) между датой заключения и датой начала действия договора/доп. соглашения»,«isCritical»:false,«exceptionCode»:«1»,«path»:«insuranceContract»},{«code»:«13002001»,«description»:«БСО ХХХ ХХХХХХ не найден в Системе.»,«isCritical»:true}

Для разрешения подобных ситуаций для полисов ОСАГО добавлен доп.атрибут «Дата выдачи бланка договора/доп.соглашения страхователю». При первой попытке сохранения атрибут заполняется автоматически. Если по каким-то причинам дата указана неверно, то измените значение атрибута вручную и повторите операцию сохранения в РСА.

Сравните дату досрочного прекращения договора с датой начала действия договора или с датой начала действия последнего аддендума. Если дата начала действия договора или дата начала действия последнего аддендума позже даты расторжения, то скорее всего это некорректно, и по этой причине договор не сохраняется в РСА.

Для смены статуса договора/доп. соглашения вы можете воспользоваться документом «Смена статуса полиса в АИС ОСАГО 2».

Важно: для отмены в РСА расторжения договор в КИАС в этот момент должен находиться в соответствующем статусе (Прекращён).

В разделе «Формуляр» экранной карточки договора ОСАГО добавлена графа, в которой отображаются текущий статус сохранения договора в АИС ОСАГО. Корректные, законченные статусы (1) выделяются шрифтом зеленого цвета, остальные - шрифтом бордового цвета.

• «Не сохранен в АИС ОСАГО»:

договор только заведён в КИАС, ещё не сохранялся;

договор находится на сохранении в АИС ОСАГО;

выполнялась попытка сохранения договора в АИС ОСАГО, но возникли ошибки.

• «Проект полиса сохранен в АИС ОСАГО»:

котировка сохранена в АИС ОСАГО;

промежуточный статус для сохранения договора с электронным полисом (с установленной галочкой «Электронный полис» на формуляре договора).

• «Договор сохранен в АИС ОСАГО» (1):

договор сохранён в АИС САГО.

• «Проект аддендума сохранен в АИС ОСАГО»:

котировка сохранена в АИС ОСАГО;

промежуточный статус для сохранения договора с электронным полисом (с установленной галочкой «Электронный полис» на формуляре договора).

• «Аддендум сохранен в АИС ОСАГО» (1):

аддендум сохранён в АИС ОСАГО.

• «Проект расторжения сохранен в АИС ОСАГО»

обычно это промежуточный статус для сохранения расторжения договора с электронным полисом (с установленной галочкой «Электронный полис» на формуляре договора).

• «Расторжение сохранено в АИС ОСАГО» (1)

прекращённый договор сохранён в АИС ОСАГО.

• «Аннулирован в АИС ОСАГО»:

аннулирование договора сохранено в АИС ОСАГО.

Обычно это проблема неполучения значимого ответа от РСА: возвращается ответ, что продолжается обработка (точнее вы можете посмотреть в Журнале обмена указав нужное значение requestId в строке поиска для фильтрации). Для данного типа запроса вы можете изменить настройки в Шаблонах документов в скрипте обмена с АИС ОСАГО 2 «Загрузка запроса на проверку контрагента»: строка 237 - максимальное кол-во запросов статуса строка 240 - ожидание в секундах между запросами статуса В очередном обновлении КИАС эти настройки планируется вынести в параметры для удобства настройки. При «сильном» увеличении значений, просьба иметь в виду, что суммарное время работы этого скрипта не должно превышать таймаут в WEB'е, иначе есть риск массово получать ошибку «Поток находится в процессе прерывания…»

Для бумажных полисов необходимо:

1. сохранить текущее состояние договора в РСА;
2. после получения ответа об успешном завершении предыдущей операции в РСА, внести изменения на карточке контрагента (указать новые ВУ);
3. сохранить договор в РСА повторно.

В данном случае особенность в том, что нужно добавить старые права, дата выдачи которых раньше текущих. Нужно выполнить следующие действия:

1. добавить старые ВУ, удалить текущие на карточке контрагента (чтобы последними ВУ были именно старые);
2. сохранить договор в АИС ОСАГО: можно ли отправить тех.коррекцию текущего состояния или нужно создать доп.соглашение и сохранить его - уточните пожалуйста в тех.поддержке РСА;
3. после получения ответа об успешном завершении операции в РСА, вернуть текущие ВУ на карточке контрагента;
4. сохраните договор в АИС ОСАГО еще раз как тех.коррекцию.

Порядок действий пользователя при возникновении данной ошибки следующий:

1. В тех.поддержке РСА выяснить номер, присвоенный полису («ХХХ-…»), записать его в КИАС в формуляр договора/котировки
2. Получить в тех.поддержке РСА подтверждение о переводе полиса в статус «Не определен» (действует 1 сутки, затем нужно обращаться снова в РСА)
3. Завершить оформление полиса, используя документ:

• «Оформление договора е-ОСАГО из котировки», указывая в атрибуте полную котировку - если полис оформлялся в WEB CUSTOMER;
• «Оформление полиса е-ОСАГО в РСА из договора», указывая в атрибуте договор - если полис оформлялся с ЭКД ОСАГО.

Данная ошибка при сохранении возникает в случае, когда дата подписания(заключения) электронного полиса (договора/ аддендума) отличается от текущей даты.

Для избежания получения данной ошибки, дату подписания электронного полиса (аддендума) следует указывать не позже текущей.

Для управления информационным обменом по суброгации в рамках КАСКО-ОСАГО на карточке регрессно-суброгационного дела (ЭКРС) предусмотрено отображение разделов «Второй участник страхового события» и «Обмен сообщениями с ИРЦ РСА» (по умолчанию эти разделы на ЭКРС скрыты). Для того чтобы на ЭКРС эти разделы отображались, должны быть соблюдены следующие условия:

• экранная форма убытка — «Убыток по автострахованию»
• в качестве ответчика должен выступать контрагент – юридическое лицо;
• на карточке контрагента-ответчика должен быть заполнен код страховщика для АПК ИРЦ ОСАГО в системном дополнительном атрибуте «Код страховщика для АПК ИРЦ ОСАГО»;
• должна быть установлена галочка в поле «Требование к ответчику подлежит урегулированию в рамках ПВУ по ОСАГО»
• Работа с этими разделами аналогична функционалу ПВУ.

Проанализируйте историю изменения убытка на предмет того, был ли в карточке этого убытка установлен признак «Видеофиксация ГЛОНАСС/GPS» на момент выставления требования. Исходящий XML по выставленному требованию, который передается в РСА, можно посмотреть в журнале обмена с АИС ПВУ РСА.

В договоре необходимо указать признак «Без ограничений по лицам, допущенным к управлению» (значение или «да» или «нет»). Расположен в правом нижнем углу раздела «Объект(ы) страхования/ Условия страхования». Если в договоре присутствуют лица, допущенные к управлению, то необходимо проставить и затем снять данный признак. Если договор без ограничений по лицам, то должен быть установлен соответствующий признак.

Для эл.полисов (серии ХХХ) проверка наличия бланка/номера осуществляется по документу вида «Электронный полис» с соответствующим номером в статусе отличном от «Аннулирован».

Возможные причины возникновения ошибки:

• в системе несколько документов вида «Электронный полис»;
• документ «Электронный полис» с необходимым номером в системе один, но находится в статусе «Аннулирован»;
• документ «Электронный полис» отсутствует в системе.

Для этой цели предусмотрен документ «ПВУ. Запрос копии сообщения» (расположен в узле «Документы по бизнес-процессам» - «Транзитная зона»), с помощью которого вы можете запрашивать как копии необходимых сообщений, так и их статус.

Краткий порядок работы с документом:

Запрос копии сообщения:

• В табличной части документа заполняете необходимые идентификаторы и типы входящих сообщений (заявка, требование, уведомление).
• По кнопке «Сформировать запрос копий» формируется запрос копий в АИС ПВУ. ISN запроса (AgrRefundXml.ISN) записывается в колонку «ISN запроса копии».
• По прошествии некоторого времени (рекомендуем подождать ~10 минут) нажимаете кнопку «Обработать результаты». При этом выполняется поиск полученной из АИС ПВУ копии + восстановление все цепочки сообщений (поиск статусов сообщений, требований по заявке и т.п.). !!! Процесс может занять длительное время !!!.

Запрос текущего статуса сообщения (входящих либо исходящих):

• В табличной части документа заполняете необходимые идентификаторы и типы сообщения (заявка, требование, уведомление).
• По кнопке «Сформировать запрос статуса» формируются запросы статусов сообщений в АИС ПВУ.
• В случае штатной работы из АИС ПВУ в течении некоторого времени (до десятков минут) выгружаются сообщения изменения статусов, которые обрабатываются штатным образом и меняют информацию в карточках убытков.

На форме договора ОСАГО есть кнопка «Запросить КБМ в РСА». При нажатии управляющего элемента «стрелка» рядом с данной кнопкой откроется всплывающий список.

В нем доступен управляющий элемент «Запросить в РСА сведения о ТО», который необходимо нажать.

Для замены водительского удостоверения необходимо воспользоваться документом «Замена ВУ», расположен «Документы по бизнес-процессам» - «АИС ОСАГО 2».

Документ предназначен для корректного сохранения договора ОСАГО в ДиКБМ в случае замены водительского удостоверения (в/у).

Используется только при наличии следующих условий:

• в разделе «Документы по договору» присутствует документ вида «Запрос КБМ в РСА», содержащий в столбце «Документ» данные о старом в/у;
• контрагент, у которого поменялось в/у, включён в список участников договора в качестве ЛДУ.

При замене в/у у контрагента, который включён в список участников договора в качестве ЛДУ, новое в/у вносится в карточку контрагента такого участника, после чего в разделе договора «Документы по договору» нужно создать документ вида «Замена ВУ».

По кнопке "Провести" в документе «Замена ВУ» производится сохранение договора в РСА ДиКБМ с данными о старом и новом в/у.

В случае отсутствия документа, необходимо подать заявку в СПЛС на установку данного документа.

«Все сведения по договору, заключенному через Е-Гарант, полученные из РСА фиксируются в документе «Данные из Е-Гарант» (см. в разделе «Документы по договору») для возможного использования в дальнейшем»

Экспресс-котировку на аддендум возможно создать, если дата окончания версии по ОСАГО позже, чем дата окончания договора, для которого необходимо создать котировку. Необходимо изменить дату окончания версии продукта «ОСАГО» на Фабрике продуктов.

При расчёте премии по аддендуму ОСАГО коэффициенты пересчитываются на дату аддендума, при условии изменения влияющих на них факторов.

Это штатное поведение системы, так работает данный функционал.

Вероятно, данный договор был получен из внешних источников (например, через WEB партнера).

Рекомендации:

Вариант 1:

1. Сделать копию данного договора. Запросить в этой копии КБМ. Будет создан документ «Запрос КБМ в РСА» по этим же водителям.
2. Привязать документ «Запрос КБМ в РСА» к оригинальному договору (в поле документ-основание для каждого участника и в раздел документы по договору).
3. Попытаться выполнить сохранение аддендума.

Вариант 2:

1. Сделать копию данного договора. Запросить в этой копии КБМ. Будет создан документ «Запрос КБМ в РСА» по этим же водителям.
2. Привязать документ «Запрос КБМ в РСА» к оригинальному договору (в поле документ-основание для каждого участника и в раздел документы по договору).
3. Аннулировать копию договора. Попытаться сохранить оригинал договора. (если электронный полис - через документ «Тех.коррекция эл.полиса в АИС ОСАГО 2»)
4. После подтверждения сохранения оригинала договора, выполнить попытку сохранения аддендума.

В данном случае необходимо внести в график платежей строки на дату дополнительного соглашения со знаками «минус» в суммах.

Пример дат,по первичным условиям:

• Дата подписания -19.10.2018
• Дата начала -20.12.2018
• Дата окончания -19.12.2018
• по аддендуму (дата подписания аддендума-12.11.2018):
• Дата начала -15.12.2018
• Дата окончания -14.12.2018

• Необходимый порядок действий:
• регистрируется аддендум;
• в окне «Изменения условий договора» указываете: подписан 12.11.2018 начало 12.11.2018);
• далее в аддендуме меняем «Дату начала» (на формуляре договора) на 15.12.2018;
• в разделе «Последние изменения по договору» (на формуляре договора) указываете начало 15.12.2018;
• добавляете новое условие (с теми же данными) устанавливаете дата начала 15.12.2018, окончания 14.12.2018;
• выпускаете договор;
• расторгаете «не верное условие»;
• перекидываете премию с «неверного условия» на «созданное условие».

При расторжении договора, который не вступил в силу (дата расторжения раньше даты начала договора), убыток не формируется, а договор признаётся недействительным. Все сформированные операции по договору будут отсторнированы Инспектором КИАС.

Вы столкнулись с ограничением системы. При регистрации страхового акта и оценке ЗНУ в качестве валюты можно выбрать либо рубли, либо валюту договора. В данном случае рекомендуем поступить следующим образом:

1. Вам необходимо рассчитать сумму в рублях по курсу по валюте заявленного убытка. Указать сумму в рублях при оценке ЗНУ и в Страховом акте. Отметку о том, что убыток пришел в валюте ставить в примечании.
2. Так как валютные платежки не выгружаются из КИАС, а создаются в клиент-банке, то РВ в данном случае не играет роли, в нем может быть сумма в валюте убытка.
3. Платите в валюте через клиент-банк.
4. Пришедшее валютное платежное поручение в валюте привязываете к операции оплаты в убытке.

В случае необходимости провести оплату одному контрагенту нескольких платежей с разными валютами мы рекомендуем разделять выплату на разные документы «Распоряжения на выплату» (одно РВ = одна валюта).

Для отзыва договоров ОСГОП/ОСОПО в КИАС рекомендуем воспользоваться документом «Отзыв авторизованных номеров ОСГОП и ОСОПО в АИС НССО» (расположен в узле «Документы по бизнес-процессам»). Порядок работы с документом:

1. указываете номер договора в поле «Номер авторизации»;
2. указываете ISN сообщения вида «Получение/отзыв номера договора ОСГОП» (из Журнала обмена с АИС НССО) в поле «Идентификационный номер сообщения в КИС СК»;
3. нажимаете кнопку «Отозвать номера из НССО».

Для быстрого поиска ISN сообщения с запросом номера вы можете воспользоваться следующим запросом (меню Отчёты - SQL отчёты):

SELECT ISN, Created, Remark FROM nssoxml
WHERE Classisn = 224118
AND remark LIKE '%Успешно выполнена авторизация номера%'
AND remark LIKE '%................%'

где в последней строке между %% необходимо ввести номер договора, который нужно отозвать.

• В первичных полисах дата begin_date указывается из поля «Начало» (формуляр договора).
• В дополнительных соглашениях дата begin_date указывается из поля «Начало» (формуляр договора, раздел Последние изменения по договору).
• В досрочном расторжении дата begin_date указывается из поля «Дата расторжения» + 1 день (из формы Убытка на возврат премии).

Данные ошибки возвращается в случае, если нарушается порядок сохранения данных - оформили прекращение договора не дождавшись его сохранения.

Из-за этого, данные о сохранении (ExtSystemKey) записываются не в договоре, а в убытке на возврат и при сохранении срабатывают соответствующие ФЛК НССО.
Очистите ExtSystemKey в убытке на возврат и повторите попытку сохранения в НССО (при этом будет применен метод CONTR_J_ACCEPT).

Причины прекращений для ОСОПО и ОСГОП вносятся конечными пользователями самостоятельно в системный справочник Страхование: Причины расторжения договора и затем настраиваются на Фабрике продуктов КИАС (Описание продуктов → Ограничения и оговорки → Причины досрочного расторжения договора).

При сохранении расторжения в АИС НССО из КИАС передаются сведения о расторжении, в т.ч. параметры «Возвращаемая часть ранее оплаченной страховой премии» в теге <contract_cancel_amount> и «Изменение премии по договору» в теге <insurance_premium>.

Если расторжение выполнялось штатно, ошибки не возникнет, так как в КИАС заложен алгоритм расчета суммы возврата в соответствии с ППД НССО!

Появление такой ошибки обычно вызвано тем, что пользователь вручную изменяет данные в договоре или убытке на возврат премии после выполнения расторжения.

Для того чтобы успешно сохранить расторжение в НССО необходимо исправить данные, чтобы параметры «Возвращаемая часть ранее оплаченной страховой премии» и «Изменение премии по договору» соответствовали правилу формально-логического контроля АИС НССО.

• Параметр «Возвращаемая часть ранее оплаченной страховой премии» рассчитывается следующим образом:

При сохранении расторжения договора в теге <contract_cancel_amount> передаётся сумма значений поля «Возврат, руб.» по всем строкам в карточке убытка на возврат премии.

В случае оплаты премии двумя платежами, и, если при этом на дату расторжения срок оплаты второго взноса ещё не наступил — данный параметр рассчитывается из оплаченной премии.

• Параметр «Изменение премии по договору» рассчитывается следующим образом:

При сохранении расторжения договора в теге <insurance_premium> передаётся сумма значений [поля («Страх. прем.»)*(количество дней действия договора до расторжения)/(количество дней действия по договору + 1)] по всем строкам таблицы из карточки убытка на возврат премии. Полученная сумма округляется до 2х знаков после запятой.

При возникновении данной ошибки необходимо сделать следующее:

• в первоначальном договоре изменить статус «Изменен по доп.соглашению» на «Подписан»;
• выполнить сохранение в БСИ, обязательно дождаться подтверждения (сохранение должно пройти с ошибкой валидации вида «Не указана дата оплаты страховой премии»);
• изменить статус обратно на «Изменен по доп.соглашению»;
• перейти к следующему состоянию договора (кроме последнего), где повторить шаги 1-3.

Данная ситуация может возникнуть, например, когда произошло событие – осыпь наледи с крыши здания на припаркованный автомобиль и потенциальным виновником является организация обслуживающая здание. В таком случае возникает накладывание проверок:

• штатная проверка КИАС, которая не позволяет оставить поле «Виновное лицо» пустым;
• проверка из БСИ «ORA-20444: Нельзя передавать в БСИ в качестве потерпевших/водителей-виновников юр.лиц !».

Для решения данной ситуации необходимо в качестве виновного лица указать технического контрагента: «КОНТРАГЕНТ ПОДЛЕЖИТ ЗАМЕНЕ» (это краткое наименование).

При получении ошибки данного типа необходимо в договор исходящего перестрахования на обрабатываемый год добавить соответствующего участника.

Ошибка данного типа может означать, что не произведена одна из следующих настроек:

• не настроен документ Документы по Re НССО (ОСГОП);
• не настроен документ Документы по Re НССО (ОСОПО);
• на Фабрике продуктов для продуктов по входящему перестрахованию ОСОПО и ОСГОП не установлены правило/риск по умолчанию и класс/тип объекта по умолчанию.

При получении ошибки данного типа необходимо найти документ по Разделу 1 и нажать управляющий элемент «Провести». Только после этого приступать к проведению следующих разделов.

В том случае, если Раздел 1 пустой также требуется нажать управляющий элемент «Провести».

Для исправления данной ошибки необходимо на Фабрике продуктов по продукту «Вх ОСГОП» или «Вх ОСОПО» в разделе убытки установить значение: «Разрешить регистрацию убытков до начала действия/даты подписания договора».

Данная ошибка может возникать при передаче портфеля одного перестраховщика, другому.

Для исправления ошибки необходимо проверить совпадает контрагент по бордеро с контрагентами по договорам. Если в договоре указан другой контрагент, то его необходимо заменить, на контрагента указанного в бордеро и после этого провести документ.

При появлении данного вида ошибки необходимо проанализировать причины его не попадания, для этого:

• уточнить какая дата подписания данного договора в КИАС;
• проверить все бордеро исх. 1 раздела с датой регистрации следующим месяцем после даты подписания договора по контрагенту СОГАЗ. Всели бордеро проведены? Если нет, то провести и повторить попытку проведения, текущего бордеро;
• если бордеро по предыдущему пункту не найдено или проведение не помогло, то нужно проверить Журнал обмена с АИС НССО - есть ли там красные строки за весь следующий месяц после даты подписания договора по контрагенту;
• если в журнале нет не проанализированных бордеро – написать письмо в НССО, с просьбой уточнить в каком акте был передан на перестрахование данный договор по текущему перестраховщику. Если в ответе НССО будет указано бордеро, которого нет в КИАС, то необходимо попросить сотрудников повторно отправить данное бордеро на адаптер. После получения бордеро, акт автоматически сформируется в КИАС.

Данная ошибка возникает при автоматической обработке или при нажатии на управляющий элемент Провести на Акте или Счете премий и убытков.

При появлении данной ошибки необходимо сравнить суммы по строкам в графах «Сумма платежа» и «Сумма операций». Значение сумм должно быть равно, вне зависимости от знака операции.

Далее необходимо по выявленному акту разобраться, почему в КИАС сумма по операциям отличается от данных пришедших из НССО.

При возникновении данной ошибки необходимо в Акте по строке № 17 проверить статус операционного документа. Данный документ должен быть в статусе «В работе», для возможности включения в него операций.

В зависимости от бизнес-процессов, пользователи самостоятельно решают, как поступить с документом: откатить в статус «В работе» или заменить на новый операционный документ.

А) Ошибка может возникать при проведении документа «Исходящее Раздел 1 (премии) (ОСОПО/ОСГОП)».

Ошибка данного типа может означать, что в договоре исходящего перестрахования контрагент по документу указан дважды в условиях секции.

В данном случае необходимо удалить за двоенного контрагента у которого нет перестраховочных условий.

Б) Ошибка может возникать при проведении документов «Исходящее Раздел 4 (заявленные) (ОСОПО/ОСГОП)» и «Исходящее Раздел 7 (урегулированные) (ОСОПО/ОСГОП)».

Ошибка данного типа может означать, что в КИАС зарегистрировано несколько претензий с одинаковым номером, указанным по одной из строк в документе.

В данном случае необходимо найти за двоенную претензию и скорректировать в не нужной претензии номер.

Ошибка может возникнуть при попытке проведения Анализа бордеро в Журнале Обмена с АИС НССО.

Для исправления ошибки необходимо проверить корректность заполнения настроечных документов: «Настройка договоров Re (ОСОПО)». В документе должны быть заполнены все поля, в том числе и «Брокер» (с 2018 года в данной графе необходимо указывать контрагента Акционерное общество «Российская национальная перестраховочная компания»)

Ошибка возникает из-за того, что в НССО был сохранен договор с указанным номером, но сейчас по каким-то причинам данного договора нет в системе или он в статусе «Аннулирован».

Для решения проблемы нужно разобраться по каким причинам договора нет в системе или он аннулирован и решить, как учитывать операции по текущему и будущим бордеро.

Для решения данной задачи необходимо воспользоваться документом: «Список ТС, запрещенных для e-ОСАГО», узел «Документы по бизнес-процессам».

В WebCustomer данные о диагностической карте заполняются на основании результатов вызова проверки ТС.
Есть данные - заполнятся, нет - нет.

В WebSale запрос данных о диагностической карте выполнялся в рамках метода запроса КБМ (при нажатии кнопки «Запросить КБМ в РСА»).

Для включения поддержки табличных документов в WebSale необходимо в файле web.config в разделе appSettings установить параметр:
<add key=«UseDefaultDocForm» value=«true»/>

Это означает, что несистемное приложение использует один из системных AppId или для несистемного приложения в параметрах КИАС настроен ключ авторизации, а приложение не передает сформированный на его основе токен.

Для решения данной проблемы:

• попробуйте выполнить перезапуск сервиса;
• проверьте нет ли в настройке веб-приложений дублирующихся записей.

Для перехода из режима учета адресов ФИАС в режим КЛАДР необходимо переключить КИАС обратно в режим использования КЛАДР, но скрипты для обратного маппинга адресов ФИАС - КЛАДР ЛС не предоставляет. Эти операции Вам придется выполнять собственными силами.

Переключение на новый режим осуществляется путем простого изменения значения соответствующей настройки в «Параметрах КИАС». Однако, в связи с тем, что до выпуска обновления 4.0.0.0 все адреса в КИАС выбирались из справочников КЛАДР, дополнительно требуется выполнить ряд операций по установке ссылок в новых полях (ссылки на соответствующие элементы справочников ФИАС). Подробную инструкцию по переходу и скрипты для маппинга ссылок КЛАДР - ФИАС Вы можете получить, оформив соответствующий запрос в СПЛС.

Более подробную информацию смотрите в документе Новый режим учета адресов в КИАС – справочники ФИАС

Аббревиатура ФИАС расшифровывается как «Федеральная информационная адресная система». Эту систему поддерживает ФНС России, которая поставляет справочники адресов РФ в двух форматах: КЛАДР и ФИАС. Загрузить справочники можно бесплатно на сайте fias.nalog.ru.

Начиная с обновления 4.0.0.0 КИАС кроме справочников формате КЛАДР поддерживает и режим учета адресов с использованием справочников в формате ФИАС. Необходимость поддержки нового режима работы КИАС в первую очередь была определена требованиями РСА в связи с вводом в эксплуатацию системы АИС ОСАГО 2.0, которая использует исключительно справочники ФИАС. Кроме того, от обслуживания справочников КЛАДР планирует отказаться ФНС России.

Необходимо также отметить, что структура справочников ФИАС лучше отражает фактическую организацию адресных объектов в РФ, обновляется гораздо чаще и содержит более полную и актуальную информацию по сравнению со справочниками КЛАДР. Таким образом компании, оперирующие ОСАГО и не перешедшие на использование справочников ФИАС, могут в будущем столкнуться с проблемами при обмене с внешними системами.

Для взаимодействия с ФИАС в КИАС включен новый системный пакет FIAS_UTILS.

В настоящее время переход не обязателен, но настоятельно рекомендован всем клиентам, оперирующим ОСАГО, т.к.:

• Несмотря на то, что скрипты обмена с РСА поддерживают оба режима (КЛАДР/ФИАС) сам АИС 2.0 поддерживает только ФИАС. А т.к. справочники КЛАДР и ФИАС содержат немного разное наполнение, хотя и поставляются одной организаций, то при обмене с РСА очень вероятны ошибки вида «Не указан код ФИАС…».
• В случае выхода новых тарифов по ОСАГО в части коэффициентов территории, соответствующие доработки процедур расчета премии в КИАС будут выполнены только для режима «ФИАС». Новые коэффициенты (если они появятся) для режима «КЛАДР» поддерживаться не будут.
• Начиная с обновления, следующего после обновления 4.0.0.0, поддержка справочников КЛАДР больше не будет осуществляться в рамках СТП.

Для передачи XML в структуре данных интеграционной шины он должен быть обрамлен CDATA.

Если в URL должны быть включены параметры, то эти параметры относятся к категории GET-параметров. В этом случае они должны быть включены в коллекцию GET выходного XML в нотации NAME-VALUE. Пример:

<GET>
	<row>
		<NAME>id</NAME>
		<VALUE>123456789</VALUE>
	</row>
</GET>

Ошибка возникает при проведении бордеро НССО 4 и 7 разделов. Для исправления данной ошибки необходимо на Фабрике продуктов по продукту «Вх ОСГОП» или «Вх ОСОПО» в разделе убытки установить значение: «Разрешить регистрацию убытков до начала действия/даты подписания договора».

В страховой машинке проводок для определения периодов «Д.принятия к учету и Д.операции» по операциям страхового учета используется следующий подход:Периодом Даты принятия к учету - считается год даты начала первичного условия (для операций исх Ре - год даты начала условия Исх Ре), к которому формируется операция, причем если условие является дополнительным (доп. соглашением) к первичному - дата принятия к учету определяется по дате первичного условия.Периодом даты операции - считается год даты операции.В случае, если Период (год) даты операции меньше либо равен Периоду (году) даты принятия к учету-считается, что дата операции и дата принятия к учету лежат в одном периоде.В случае, если Период (год) даты операции больше Периода (года) даты принятия к учету-считается, что дата операции и дата принятия к учету лежат в разных периодах.

Кнопки АВР:

• По платежам премии за период по всем договорам;
• По платежам премии за период по указанным договорам;
• По платежам премии за период по всем договорам (с контролем КВ);
• По платежам премии за период по указанным договорам (с контролем КВ)

За работу указанных кнопок отвечает один обработчик DOCS_UTILS.DOCAGENTREPPROCESS, который в свою очередь вызывает скрипт описанный в параметрах КИАС: Расчеты с посредником - Скрипт расчета вознаграждения в АВР и УАВР.