содержание .. 1 2 3 ..
Техническое задание. Разработка фрагмента Информационной системы межоператорского взаимодействия (2016 год) - часть 2
Автомобильная
В чью пользу
дорога / платный
будет
Стадия
№
участок
Эмитент
осуществляться
проекта
автомобильной
сбор платы
дороги
(ЦКАД). Пусковой
определен на
комплекс № 5
основе отдельного
конкурса
10
Скоростная
ООО «Автодор-
Государственная
Строительство
автомобильная дорога
Платные Дорогиª
компания
М-11 «Москва -
«Автодорª
Санкт-Петербургª на
участке км 208 - км
258
11
Скоростная
ООО «Автодор-
Государственная
Строительство
автомобильная дорога
Платные Дорогиª
компания
М-11 «Москва -
«Автодорª
Санкт-Петербургª на
участке км 334 - км
543
12
Скоростная
ООО «Магистраль
Государственная
Строительство
автомобильная дорога
двух столицª
компания
М-11 «Москва -
«Автодорª
Санкт-Петербургª на
участке км
43 - км
684
13
Автомобильная
Подлежит
Государственная
Строительство
дорога М-3
определению по
компания
«Украинаª - от
результатам
«Автодорª
40
Автомобильная
В чью пользу
дорога / платный
будет
Стадия
№
участок
Эмитент
осуществляться
проекта
автомобильной
сбор платы
дороги
Москвы через Калугу,
конкурса
Брянск до границы с
Украиной (на Киев)
на участке км 124 -
км 194
10.3 Характеристика процессов, связанных с взиманием платы за проезд,
которые реализуются на объектах автоматизации
Исходя из вышеприведенных данных об инфраструктуре платных участков
дорог, которые входят в объект автоматизации СМВ, можно выделить следующий
перечень информационных систем операторов дорог, с которыми будет
взаимодействовать Система:
СВП второго уровня Rutoll;
СВП второго уровня Tecsidel;
СВП третьего уровня Rutoll;
СВП третьего уровня CosPro;
СВП второго уровня GEA.
Детальное описание информационных систем, заявленных выше, и форматов
их данных содержится в документации от производителей этих ИС.
Плата взимается за проезд транспортных средств по участкам платных
автодорог с закрытой и открытой системой взимания платы.
Открытая система взимания платы за проезд подразумевает порядок, при
котором плата взимается при проезде через единственный ПВП, расположенный на
41
въезде, выезде или на протяжении платной дороги, участка дороги или дорожного
объекта. При открытой системе размер платы не зависит от фактически
пройденного расстояния, а въезд на платную дорогу с примыкающих дорог и выезд
с платной дороги на примыкающие объекты остаётся свободным.
Закрытая система взимания платы за проезд подразумевает порядок, при
котором оплата производится на выезде с платной дороги по талону (билету),
полученному пользователем на въезде на платную дорогу. При закрытой системе
взимания платы размер платы зависит от фактически пройденного расстояния, а
ПВП устанавливаются на всех въездах и выездах с платной дороги (дорожного
объекта), что позволяет обеспечить полный контроль за движением.
Пункт взимания платы (ПВП) - это часть системы взимания платы, комплекс
специализированных сооружений платной автомагистрали, оборудованный
системами взимания платы за проезд, пропускного контроля и регистрации
пользователя платной автодороги.
Существует несколько способов оплаты проезда через ПВП: наличные
денежные средства либо банковские карты, бесконтактная смарт-карта (БСК), с
помощью радиопередающего устройства (транспондер). Наиболее удобными и
перспективными формами оплаты являются транспондеры.
Транспондер представляет собой приёмо-передающее устройство,
предоставляющее возможность безостановочного скоростного проезда на Пунктах
взимания платы. На всех рассматриваемых платных автодорогах, входящих в
объект автоматизации, используются DSRC-транспондеры, поэтому в настоящем
документе нет необходимости анализировать и учитывать проблемы
межоператорского взаимодействия, связанные с отличиями в стандартах связи
применяемых ЭСРП. Рассмотрим детальнее процесс оплаты посредством
транспондера на ПВП и, как при этом формируются данные по транзакции проезда:
1) Транзакция проезда формируется в ходе взаимодействия специального
оборудования ПВП (антенны) и транспондера. В зависимости от введенных
42
тарифов и правил взимания платы на ПВП может также производиться
классификация ТС, фотографирование, распознавание номерного знака и
весогабаритный контроль. Эти данные так же могут дополнять данные
транзакции проезда.
2) После покупки транспондера Пользователем у Эмитента каждый транспондер
проходит процедуру инициализации, в ходе которой в его память записывается
блок информации, которую он должен передавать в ходе информационного
обмена с оборудованием ПВП в процессе оплаты проезда.
3) Таким образом, в процессе пересечения ТС Пользователя ПВП и оплаты им
проезда посредством транспондера может возникнуть следующий
информационный обмен (вся эта информация попадает в систему взимания
платы Оператора, который обслуживает проезд на ПВП и, в том числе, оплату
этого проезда посредством ЭСРП):
Информация о контракте пользователя. Эти атрибуты заполняются
всегда, так как без них невозможно сформировать транзакцию и списать
средства со счета пользователя.
Информация для чека (финансовая часть, сопроводительная информация
по требованиям локального законодательства и т.п.).
Информация об автомобиле
— заполняются необходимые для
тарификации и контроля атрибуты автомобиля.
Информация о транспондере (заводской номер, учетный номер PAN и
прочие возможные идентификаторы, применимые в СВП Оператора
взимания платы на участке Платной дороги).
Информация о водителе и пассажирах (если количество пассажиров
учитывается в тарифе).
43
11 ТРЕБОВАНИЯ К СИСТЕМЕ
11.1 Требования к Системе в целом
Требования к структуре и функционированию Системы
11.1.1.1
Архитектура Системы
Функциональная архитектура Системы представлена ниже
(Рисунок
1)
(функциональная архитектура детально прорабатывается на этапе Технического
проектирования):
44
Рисунок 1. Архитектура ИСМВ
11.1.1.2
Перечень подсистем, их назначение и основные характеристики
Система должна состоять из следующих подсистем:
Интеграционный сервис;
Личный кабинет ИСМВ;
Модуль биллинга;
Модуль формирования отчетов сверки;
Модуль управления Цветными списками;
Подсистема НСИ;
Модуль аналитической отчетности;
Подсистема хранения данных;
Подсистема администрирования;
Сервисная шина ИСМВ.
Назначения и основные характеристики всех вышеуказанных компонентов
ИСМВ описаны в соответствующих подразделах данного раздела ТЗ.
11.1.1.2.1 Интеграционный сервис
Интеграционный сервис предназначен для обеспечения процедур
информационного взаимодействия ИСМВ с системами взимания платы второго и
третьего уровня и ИС Эмитентов.
Детальные требования к функциям содержатся в разделе «4.2.1 Требования к
функциям Интеграционного сервисаª.
Требования к защите информации, которая участвует в обмене между
Интеграционным сервисом ИСМВ и информационными системами участников
межоператорского взаимодействия, содержатся в разделе
«4.1.9 Защита
информации от несанкционированного доступаª настоящего ТЗ.
45
Требования к формату данных, которые участвуют в обмене между
Интеграционным сервисом ИСМВ и информационными системами участников
межоператорского взаимодействия содержатся в разделе
«4.3.1 Требования к
информационному обеспечению системыª настоящего ТЗ.
Требования к информационному взаимодействию со смежными системами, в
котором участвует Интеграционный сервис ИСМВ, содержатся в разделе «4.3.1.4
Требования к информационной совместимости со смежными системамиª
настоящего ТЗ.
Требования к информационному обмену с компонентами системы, в котором
участвует Интеграционный сервис СМВ, содержатся в разделе «4.3.1.3 Требования
к информационному обмену между компонентами системыª.
11.1.1.2.2 Личный кабинет ИСМВ
Личный кабинет ИСМВ предназначен для реализации пользовательского
интерфейса, который обеспечивает доступ для сотрудников организаций-
участников СМВ, к следующим функциям ИСМВ:
авторизация пользователя в Личном кабинете ИСМВ;
функции процесса управления реестром Роуминговых транзакций для
целей процедуры их верификации;
функции процесса корректировки Роуминговых транзакций для целей
процессов верификации и согласования Роуминговых транзакций
между организациями-участниками СМВ;
функции процесса оспаривания Роуминговых транзакций и
согласования корректировок по Роуминговым транзакциям;
доступ к отчетам сверки, которые формируются в Модуле
формирования отчетов сверки;
доступ к аналитическим отчетам, которые формируются в Модуле
аналитической отчетности.
46
Детальные требования к функциям содержатся в разделе «4.2.2 Требования к
функциям Личного кабинета ИСМВª.
Требования к пользовательскому интерфейсу Личного кабинета ИСМВ
содержатся в разделе «4.1.6.2 Перечень пользовательских интерфейсов, которые
должны быть реализованы в ИСМВª.
Требования к информационному обмену с компонентами системы, в котором
участвует Личный кабинет ИСМВ, содержатся в разделе «4.3.1.3 Требования к
информационному обмену между компонентами системыª.
11.1.1.2.3 Модуль биллинга
Модуль биллинга предназначен для реализации следующих процессов и
функций ИСМВ:
определение Эмитента для ЭСРП, который фигурирует в Роуминговой
транзакции;
определение Получателя платежа за Роуминговый проезд;
дополнительная верификация с целью контроля в ИСМВ Роуминговых
транзакций, полученных от СВП;
проверка и контроль правильности расчетов в данных по стоимости
(оплате) проезда в транзакциях проезда, полученных от СВП;
расчет стоимости проезда по платному участку открытого типа;
расчет стоимости проезда по платному участку закрытого типа;
расчет значения Роуминговых лимитов
(балансов ЭСРП), которые
необходимы для корректного формирования данных по Цветным
спискам в ИСВМ.
Детальные требования к функциям содержатся в разделе «4.2.3 Требования к
функциям Модуля биллингаª.
47
Требования к информационному обмену с компонентами системы, в котором
участвует Модуль биллинга ИСМВ, содержатся в разделе «4.3.1.3 Требования к
информационному обмену между компонентами системыª.
11.1.1.2.4 Модуль формирования отчетов сверки
Модуль формирования отчетов сверки предназначен для реализации
следующих функций ИСМВ:
генерация отчетов сверки, которые необходимы для поддержки
процессов взаиморасчетов между организациями-участниками СМВ;
расчет сумм Роуминговых комиссий.
Детальные требования к функциям содержатся в разделе «4.2.4 Требования к
функциям Модуля формирования отчетов сверкиª.
Требования к формату данных отчетов Модуля формирования отчетов
сверки содержатся в разделе «4.3.1 Требования к информационному обеспечению
системыª настоящего ТЗ.
Требования к информационному обмену с компонентами системы, в котором
участвует Модуль формирования отчетов сверки ИСВМ, содержатся в разделе
«4.3.1.3 Требования к информационному обмену между компонентами системыª.
11.1.1.2.5 Модуль управления Цветными списками
Модуль управления Цветными списками предназначен для реализации
следующих функций ИСМВ:
расчет Серых и Белых списков для ЭСРП на основании данных по
Роуминговым лимитам ЭСРП и стоимостям проезда через ПВП;
формирование Цветных списков ЭСРП персонально для каждого ПВП
для последующей их передачи в СВП посредством Интеграционного
сервиса ИСМВ.
48
Детальные требования к функциям содержатся в разделе «4.2. Требования к
функциям Модуля управления Цветными спискамиª.
Требования к формату данных Модуля управления Цветными списками
содержатся в разделе
«4.3.1 Требования к информационному обеспечению
системыª настоящего ТЗ.
Требования к информационному обмену с компонентами системы, в котором
участвует Модуль управления Цветными списками, содержатся в разделе «4.3.1.3
Требования к информационному обмену между компонентами системыª.
11.1.1.2.6 Подсистема НСИ
Подсистема НСИ предназначена для ведения и просмотра информации,
которая не претерпевает существенных изменений в процессах, автоматизируемых
Системой. К такого рода информации относятся следующие основные данные
(классификаторы и справочная информация):
Основные справочные данные (Участники СМВ, Участки платных
дорог, ПВП и др);
Тарифы для расчета и контроля стоимости проезда по платным
участкам дорог;
Сведения по Роуминговым ЭСРП (реестр).
Детальные требования к функциям содержатся в разделе «4.2.6 Требования к
функциям Подсистемы НСИª.
Требования к формату данных справочников Подсистемы НСИ содержатся в
разделе «4.3.1 Требования к информационному обеспечению системыª настоящего
ТЗ.
Требования к информационному обмену с компонентами системы, в котором
участвует Подсистема НСИ, содержатся в разделе
«4.3.1.3 Требования к
информационному обмену между компонентами системыª.
49
11.1.1.2.7 Модуль аналитической отчетности
Модуль аналитической отчетности предназначен для генерации отчетов,
отражающих статистику и различные аналитические показатели реализации
процессов межоператорского взаимодействия.
Детальные требования к функциям содержатся в разделе «4.2.7 Требования к
функциям Подсистемы аналитической отчетностиª.
Требования к формату данных отчетов Подсистемы аналитической
отчетности содержатся в разделе
«4.3.1 Требования к информационному
обеспечению системыª настоящего ТЗ.
Требования к информационному обмену с компонентами системы, в котором
участвует Модуль аналитической отчетности, содержатся в разделе
«4.3.1.3
Требования к информационному обмену между компонентами системыª.
11.1.1.2.8 Подсистема хранения данных
Подсистема хранения данных предназначена для:
Реализации реляционного хранилища данных ИСМВ (ОХД ИСМВ) -
база данных Системы и функции СУБД.
Реализации хранилища для фото и видео данных с полос ПВП
(Медиахранилище ИСМВ).
Детальные требования к функциям содержатся в разделе «4.2.8 Требования к
функциям Подсистемы хранения данныхª.
Требования к формату данных Подсистемы хранения данных содержатся в
разделе «4.3.1 Требования к информационному обеспечению системыª настоящего
ТЗ.
50
Требования к информационному обмену с компонентами системы, в котором
участвует Подсистема хранения данных, содержатся в разделе «4.3.1.3 Требования
к информационному обмену между компонентами системыª.
11.1.1.2.9 Подсистема администрирования
Подсистема администрирования предназначена для реализации следующих
процессов ИСМВ:
мониторинг работоспособности ИСМВ в целом и ее компонентов (в
частности, мониторинг сбоев и ошибок в передаче данных);
централизованное управление учетными записями пользователей и
правами их доступа в ИСМВ;
активация новых участников, подключаемых к СМВ, в Системе.
Детальные требования к функциям содержатся в разделе «4.2.9 Требования к
функциям Подсистемы администрированияª.
Требования к информационному обмену с компонентами системы, в котором
участвует Подсистема администрирования, содержатся в разделе
«4.3.1.3
Требования к информационному обмену между компонентами системыª.
11.1.1.2.10 Сервисная шина ИСМВ
Сервисная шина ИСМВ предназначена для:
обеспечения процедур использования данных, полученных от внешних
систем Интеграционным сервисом ИСМВ, в процессах, которые
реализуются другими подсистемами ИСМВ;
обеспечения централизованного и унифицированного событийно-
ориентированного обмена сообщениями в процессе взаимодействия
между всеми компонентами ИСМВ.
Детальные требования к функциям, к формату сообщений и
информационному обмену с компонентами ИСМВ, а также к защите информации
для Сервисной шины ИСМВ должны быть сформулированы на этапе Технического
51
проектирования ИСМВ после того, как будут определены технические решения (в
том числе, перечень коммерческого программного обеспечения), на базе которых
будут реализовываться компоненты ИСМВ.
11.1.1.3
Требования к способам и средствам связи для информационного
обмена между компонентами Системы
В качестве основного протокола взаимодействия между компонентами
Системы на транспортно-сетевом уровне необходимо использовать протокол
TCP/IP.
11.1.1.4
Требования к характеристикам взаимосвязей создаваемой
Системы со смежными системами
Смежными системами по отношению к ИСМВ являются информационные
системы организаций-участников СМВ. На момент формулирования требований
данного ТЗ это системы взимания платы (СВП-2, СВП-3), основная часть которых
описана в разделе
«3. Характеристика объекта автоматизацииª настоящего
документа.
Обмен данными между смежными системами и ИСМВ должен быть
реализован посредством Интеграционного сервиса ИСМВ.
Обмен данными между Интеграционным сервисом ИСМВ и смежными ИС
должен быть реализован по протоколу HTTP с использованием формата данных
JSON, следует предусмотреть так же варианты обмена файлами или интеграции на
уровне БД.
52
11.1.1.5
Требования к режимам функционирования Системы
ИСМВ должна поддерживаться следующие режимы функционирования:
Таблица 15. Режимы функционирования ИСМВ
Наименование режима
Характеристика режима функционирования
Основной режим
ИСМВ выполняет все свои основные функции в
функционирования
режиме 24х7 (24 часа в сутки 7 дней в неделю).
Профилактический
Временная остановка работоспособности
режим
функций системы в связи с проведением
функционирования
плановых работ по техническому обслуживанию,
модернизации программно-аппаратного
комплекса, устранение аварийных ситуаций.
Общее время проведения профилактических
работ в Системе не должно превышать 1 минут
в сутки.
11.1.1.6
Требования по диагностированию Системы
Диагностирование ИСМВ должно быть реализовано на базе стандартных
программных средств, которые используются в корпоративных системах
мониторинга ИТ-инфраструктуры Заказчика, или на базе средств, интегрируемых с
ними.
Для всех технических компонентов ИСМВ должны быть обеспечены
регулярный контроль состояния и техническое обслуживание в соответствии с
требованиями их производителей.
53
11.1.1.7
Перспективы развития, модернизации Системы
Общие требования по развитию ИСМВ:
1.
Система должна поддерживать возможности обновления версий выбранного
ПО;
2.
Система должна допускать модернизацию, в случае изменений в основных
бизнес-процессах, которые она реализует;
3.
Система должна допускать расширение функциональных возможностей за счет
создания пли приобретения дополнительных функциональных модулей при
наличии соглашения с Заказчиком и приобретении дополнительных лицензий
на ПО.
Функциональные требования по развитию ИСМВ:
1.
В ИСМВ необходимо реализовать следующие уведомления/оповещения для
Эмитента ЭСРП, информация из которых может быть использована им для
оповещения/уведомления своих Пользователей:
1.1.в ИС Эмитента должны передаваться данные о том, что обслуживаемые ими
ЭСРП в указанный момент помещены ИСМВ в Серый список для указанных
ПВП;
1.2.в ИС Эмитентов должны передаваться данные о снижении Роумингового
лимита по их ЭСРП ниже определенного уровня.
2.
В ИСМВ необходимо реализовать функционал системы мгновенных сообщений
в Личном кабинете ИСМВ, который может обеспечивать возможность
оперативной связи между сотрудниками организаций-участников СМВ по
вопросам оспаривания транзакций.
54
Требования к численности и квалификации персонала Системы
11.1.1.8
Требования к численности персонала
Для персонала, эксплуатирующего ИСМВ, должны быть определены
следующие основные функциональные роли (допускается совмещение нескольких
ролей одним лицом):
Контролёр;
Регистратор;
Бухгалтер СП;
Специалист поддержки;
Администратор ИСМВ.
Подробное описание данных ролей содержится в разделе «Приложение 6.
Описание ролей пользователей ИСМВª настоящего документа.
Детализированные требования и уточненные решения для реализации ролей
пользователей в ИСМВ должны быть определены на этапе Технического
проектирования Системы.
Численность персонала, эксплуатирующего ИСМВ, не может быть
определена на этапе формирования требований настоящего ТЗ, она будет
определяться на этапах внедрения Системы и ее промышленной эксплуатации (в
зависимости от состава и количества пользователей Системы со стороны
организаций-участников СМВ).
11.1.1.9
Требования к квалификации персонала
Требования к квалификации персонала, эксплуатирующего Систему, должны
быть определены на этапе Технического проектирования ИСМВ и зафиксированы
в соответствующих технологических инструкциях.
55
11.1.1.10 Требования к режимам работы персонала
Персонал, работающий с ИСМВ, а также выполняющий функции
её сопровождения и обслуживания, должен работать в следующих режимах:
- Конечный пользователь
- в соответствии с основным рабочим
графиком соответствующего подразделения Заказчика.
- Администраторы подсистем
- режим работы администраторов
подсистем должен соответствовать основному рабочему графику
подразделений Заказчика, осуществляющих эксплуатацию и
техническую поддержку информационных систем с требованиями по
надежности, аналогичными требованиям к подсистемам СМВ.
Показатели назначения
11.1.1.11 Параметры, характеризующие степень соответствия Системы
назначению
Система должна обеспечивать следующие количественные показатели,
которые характеризуют степень соответствия ее назначению в соответствии с
таблицей ниже (Таблица 16).
Таблица 16. Количественные показатели, характеризующие степень соответствия ИСМВ ее
назначению
Количественный показатель,
Параметр
характеризующий степень
соответствия ИСМВ ее назначению
Сбор, хранение и анализ данных
Не менее 10 000 000 транзакций в сутки
по Роуминговым транзакциям
56
Количественный показатель,
Параметр
характеризующий степень
соответствия ИСМВ ее назначению
Хранение, анализ и
Временной период хранения документов
предоставление доступа к данным
и информации в ИСМВ:
- Данные по транзакциям (в том числе,
корректировки к ним и фото проезда) -
не менее 4 лет;
- Данные по Цветным спискам - не
менее 3 лет;
- Изменения по справочным данным -
не менее 3 лет.
Общее количество транзакционных
данных в хранилище данных - не менее
4, млрд. транзакций.
Обработка данных по
Не более минут.
Роуминговым транзакциям в
ИСМВ и их передача в ИС
Эмитента
11.1.1.12 Требования к приспособляемости Системы к изменениям
Обеспечение приспособляемости системы к изменениям должно
выполняться за счет следующих возможностей ИСМВ:
возможность оперативного конфигурирования ИСМВ и ее подсистем,
не нарушающей работоспособность всей ИСМВ в целом;
возможность добавления новых отчетов и изменения существующих
без необходимости изменения программного кода компонентов
Системы.
57
11.1.1.13 Требования к сохранению работоспособности Системы в
различных вероятных условиях
В зависимости от различных вероятных условий система должна выполнять
требования, приведенные в таблице ниже.
Таблица 17. Требования к сохранению работоспособности ИСМВ в различных вероятных
условиях
Вероятное условие
Требование
Нарушения в работе системы
Уведомление администратора.
внешнего электроснабжения
Функционирование в полном объеме.
серверного оборудования
продолжительностью до 30
мин
Нарушение в работе системы
Уведомление администратора.
внешнего электроснабжения
Переключение пользователей на ближайший
серверного оборудования
доступный кластер.
продолжительностью более 30
Корректное завершение работы серверов.
мин
Выход из строя основного
Уведомление администратора.
канала связи
Переход на резервный канал.
Функционирование в полном объеме.
Выход из строя основного и
Уведомление администратора.
резервного канала связи
Создание отметки на данных, которые небыли
доставлены получателям с возможностью
доставки после восстановления каналов связи.
Выход из строя одного из
Уведомление администратора.
серверов
Автоматическое распределение нагрузки между
остальными серверами.
После восстановления работоспособности
сервера он передается в пул свободных ресурсов
58
Вероятное условие
Требование
кластера.
Выход из строя кластера
Уведомление администратора.
серверов
Переключение на ближайший доступный
кластер.
Переключение клиентов на доступный кластер.
После восстановление работоспособности
кластера происходит синхронизация данных с
остальными кластерами и после нее
переключение ближайших клиентов на кластер.
Выход из строя диска в
Уведомление администратора.
дисковом массива
Функционирование в полном объеме.
Требования к надежности
Система должна обеспечивать работу при развертывании её в нескольких
дата-центрах
(системы хранения) при наличии основного и дублирующего
кластеров.
Должна быть обеспечена скорость передачи данных между дата-центрами не
менее 100 Мб/сек.
Узлы кластера должны быть подключены к системе хранения локальной
сетью с пропускной способностью не менее 1 Гбит.
Должна быть реализована поддержка дублирования и выравнивания
(балансировки) нагрузки для обеспечения работоспособности центральных
серверов ИСМВ при выходе из строя любого сервера.
ИСМВ должна обеспечивать стабильное выполнение своих функций даже в
случае отказа какого-либо дата-центра, т.е. не должна иметь единую точку отказа.
59
Должен быть реализован постоянный контроль доступности и
работоспособности компонентов ИСМВ, корректности работы, состояния
аппаратной части, внешней среды и электропитания с многоуровневым
оповещением о нештатных ситуациях посредством различных каналов (e-mail, sms
и т.п.).
Требования к безопасности
При внедрении, эксплуатации и обслуживании технических средств системы
должны выполняться меры электробезопасности в соответствии с «Правилами
устройства электроустановокª и
«Правилами техники безопасности при
эксплуатации электроустановок потребителейª.
Аппаратное обеспечение системы должно соответствовать требованиям
пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91.
«ССБТ. Пожарная безопасность. Общие требованияª.
Должно быть обеспечено соблюдение общих требований безопасности в
соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие
требования безопасностиª при обслуживании системы в процессе эксплуатации.
Аппаратная часть системы должна быть заземлена в соответствии с
требованиями ГОСТ Р
0 71.22-2000.
«Электроустановки зданий. Часть
7.
Требования к специальным электроустановкам. Раздел
707. Заземление
оборудования обработки информацииª.
Значения эквивалентного уровня акустического шума, создаваемого
аппаратурой системы, должно соответствовать ГОСТ
21
2-84
«Средства
вычислительной техники. Общие технические требования, приемка, методы
испытаний, маркировка, упаковка, транспортирование и хранениеª.
60
Требования к эргономике и технической эстетике
11.1.1.14 Общие требования к пользовательским интерфейсам ИСМВ
Пользовательские интерфейсы, реализуемые в ИСМВ, должны отвечать
следующим требованиям:
интерфейсы подсистем должны быть типизированы;
должно быть обеспечена возможность настройки пользовательского
интерфейса;
должно быть обеспечено наличие процедур контроля, сводящие
возможные ошибки к минимуму;
интерфейс должен быть рассчитан на преимущественное
использование манипулятора типа «мышьª, т.е. управление системой
должно осуществляется с помощью набора экранных меню, кнопок,
значков и т.п. элементов. Клавиатурный режим ввода должен
используется главным образом при заполнении/редактировании
текстовых и числовых полей экранных форм.
11.1.1.15 Перечень пользовательских интерфейсов, которые должны быть
реализованы в ИСМВ
В ИСМВ должны быть реализованы следующие основные пользовательские
интерфейсы:
1. Личный кабинет ИСМВ должен объединять следующие основные интерфейсы
пользователя:
1.1.Экран авторизации в Личном кабинете ИСМВ;
1.2.Реестр Роуминговых транзакций для Эмитента, сотрудник которого
авторизовался в Личном кабинете ИСМВ, с панелью настройки фильтров
для отбора данных в реестре;
1.3.Экран просмотра и редактирования транзакции из реестра Роуминговых
транзакций;
61
1.4.Главное меню навигации по отчетам;
1.5.Экраны для просмотра и выгрузки во внешние форматы для отчетов сверки;
1.6.Экраны для просмотра и выгрузки во внешние форматы для аналитических
отчетов.
2. Web-формы ввода и редактирования для всех справочников и классификаторов
в ИСМВ;
3. Пользовательские интерфейсы системного администратора ИСМВ должны
включать следующие основные интерфейсы пользователя:
3.1.для настройки профилей пользователей и их доступа к ИСМВ;
3.2.для мониторинга работы всех компонентов ИСМВ;
3.3.для базовой настройки компонентов ИСМВ;
3.4.пользовательские интерфейсы для процедур загрузки и преобразования
данных (например, справочных);
3.5.пользовательские интерфейсы СУБД.
Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов системы
Условия эксплуатации, а также виды и периодичность обслуживания
технических средств Системы должны соответствовать требованиям по
эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в
документации завода-изготовителя (производителя) на них.
Технические средства Системы и персонал должны размещаться в
существующих помещениях Заказчика, которые по климатическим условиям
должны соответствовать ГОСТ 1 1 0-69 «Машины, приборы и другие технические
изделия. Исполнения для различных климатических районов. Категории, условия
эксплуатации, хранения и транспортирования в части воздействия климатических
факторов внешней средыª (температура окружающего воздуха от до 40 °С,
относительная влажность от 40 до 80 % при Т=2
°С, атмосферное давление от 630
до 800 мм ртутного столба). Размещение технических средств и организация
автоматизированных рабочих мест должны быть выполнены в соответствии с
62
требованиями ГОСТ
219 8-76
«Система "Человек-машина". Зал и кабины
операторов. Взаимное расположение рабочих мест. Общие эргономические
требованияª.
Для обеспечения эксплуатации оборудования должен быть разработан
одиночный ЗИП
(ЗИП-О), который используется на месте эксплуатации
оборудования. Он предназначается для поддержания безотказного состояния
системы путем замены отказавших элементов в течение периода пополнения ЗИП.
В качестве замены одиночного ЗИП
(ЗИП-О) возможно заключение
контракта на техническую поддержку 24x7 с поставщиком аппаратных средств,
предусматривающую с прибытие в случае необходимости специалиста поставщика
на место сбоя для гарантийной замены вышедшего из строя узла в течение 4х часов
с момента обращения в службу поддержки.
Компоненты СМВ должны быть реализованы в виде готовых для установки
пакетов и поддерживать автоконфигурирование для обеспечения развертывания не
более чем за 24 часа.
Требования к защите информации от несанкционированного доступа
Требования к защите информации, которая фигурирует в обмене между
Интеграционным сервисом ИСМВ и СВП-2, СВП-3:
Обмен информацией между ИСМВ и пользователями должен
происходить по безопасному соединению с использованием протокола
SSLv3 или TLSv1.0.
Дополнительная защита должна быть реализована при использовании
идентификатора и секретного ключа
(присваиваются каждому
оператору), которые применяются для подписи передаваемых данных.
ИС организации-участника СМВ, получающая данные от
Интеграционного сервиса ИСМВ, всегда должна проверять
63
соответствие сообщения его подписи. Сообщения с неверной подписью
должны игнорироваться.
ИСМВ должна обеспечивать необходимый уровень защиты
информации и приложений от ошибок, несанкционированного доступа,
преднамеренного разрушения и потери информации, поддерживать
контроль авторства информации и ее изменений, восстановление
информации при авариях и катастрофах.
11.1.1.16 Требования к информационной безопасности
Необходимо автоматическое обеспечение безопасности СМВ, в том числе
обеспечение защиты от несанкционированного доступа, преднамеренного
разрушения данных и потери информации, нарушения или остановки работы СМВ
в результате некорректных действий пользователей или внутренних процессов,
вирусов и DOS-атак из сети Интернет.
Обеспечение информационной безопасности системы должно удовлетворять
следующим требованиям:
- Защита Системы должна обеспечиваться комплексом программно-
технических средств и поддерживающих их организационных мер.
- Защита Системы должна обеспечиваться на всех технологических
этапах обработки информации и во всех режимах функционирования, в
том числе при проведении ремонтных и регламентных работ.
- Программно-технические средства защиты не должны противоречить
требованиям к Системе (по надежности, быстродействию, возможности
изменения конфигурации).
- Разграничение прав доступа пользователей и администраторов
Системы должно строиться в соответствии с их должностными
обязанностями.
64
- Передача данных по открытым каналам связи (сети Интернет) должна
производиться только с использованием защищенных соединений
(VPN-соединений и/или протокола HTTPS).
- Должен поддерживаться тайм-аут сессий.
- Доступ к данным и настройкам всех компонент системы должен быть
возможен только после аутентификации пользователя при наличии у
него необходимых прав.
- Серверы получения данных и другие аппаратные компоненты
Системы, находящиеся за пределами центрального узла, должны
поставляться в опечатанных корпусах, исключая возможность
несанкционированного подключения к портам и разъемам устройств.
11.1.1.17 Разграничения ответственности ролей при доступе к ИСМВ
Описание основных ролей и их доступа к ИСМВ содержится в разделе
«Приложение 7. Матрицы прав доступа пользователейª настоящего документа.
Окончательно роли пользователей ИСМВ, их права и ответственность
должны быть уточнены на этапе Технического проектирования ИСМВ.
11.1.1.18 Требования к защите от ошибочных действий пользователей
Ошибочные действия конечных пользователей не должны приводить к
аварийному завершению работы или потере данных.
Требования по сохранности информации при авариях
В Системе должно быть обеспечено еженедельное полное и ежесуточное
инкрементальное резервное копирование данных.
Выход из строя 2 жестких дисков дискового массива не должен сказываться
на работоспособности кластера.
Каждый дисковый массив в составе Системы должен комплектоваться
дисками горячей замены (hot spare).
65
Требования к защите от влияния внешних воздействий
Система должна иметь возможность функционирования в диапазоне
допустимых температур, влажности окружающей среды и вибраций,
установленных изготовителем аппаратных средств.
Система должна иметь возможность функционирования при колебаниях
напряжения электропитания в пределах, установленных изготовителем аппаратных
средств.
Требования к патентной чистоте
Патентная чистота Системы и ее частей должна быть обеспечена в
отношении патентов, действующих на территории Российской Федерации.
Реализация технических, программных, организационных и иных решений,
предусмотренных проектом системы, не должна приводить к нарушению
авторских и смежных прав третьих лиц.
При использовании в Системе программ (программных комплексов или
модулей), разработанных третьими лицами, условия, на которых передается право
на использование
(исполнение) этих программ, не должны накладывать
ограничений, препятствующих использованию системы по ее прямому
назначению.
Требования по стандартизации и унификации
Разработка системы должна осуществляться с использованием стандартных и
общепринятых методологий функционального моделирования.
Для работы с БД должен использоваться язык запросов A SI SQL-92 или его
диалекты.
66
В системе должны использоваться (при необходимости) общероссийские
классификаторы и словари для различных видов алфавитно-цифровой и текстовой
информации.
Унификация программных средств должны быть обеспечена за счет
применения унифицированных компонент и средств из состава:
- прикладного программного обеспечения;
- систем управления базами данных;
- сетевых операционных системах.
Дополнительные требования
11.1.1.19 Требования к масштабируемости
Увеличение мощности ИСМВ
(количество обрабатываемых в единицу
времени запросов и объем хранимых данных) должно производиться с помощью
добавления новых программных и аппаратных компонентов.
11.1.1.20 Требования к расширяемости
ИСМВ должна иметь возможность расширения функциональности за счет
создания и подключения новых программных (или аппаратных) компонентов. Для
создания новых компонентов должны использоваться готовые библиотеки
компонентов, открытые протоколы и стандарты.
11.1.1.21 Требования к унификации (тиражируемость на других объектах)
Компоненты ИСМВ должны использовать набор стандартизированных,
хорошо описанных, открытых протоколов для связи с внешними узлами;
обеспечивать возможность многократного использования проектных решений, а
также взаимозаменяемость на уровнях модулей, устройств и программно-
алгоритмического обеспечения.
67
11.1.1.22 Требования к поддержке различных временных зон
Система должна обеспечивать возможность работы в нескольких временных
зонах одновременно.
11.2 Требования к функциям (задачам), выполняемым Системой
Требования к функциям Интеграционного сервиса
Интеграционный сервис необходимо реализовать для выполнения и
поддержки процессов информационного обмена в части:
данных по Роуминговым транзакциям проезда, в том числе данные о
регистрации въезда на закрытый участок платной дороги, и их
корректировках, получаемые от СВП-2 или СВП-3;
данных по Цветным спискам ЭСРП, получаемых из ИС Эмитентов, в
том числе в их составе должны передаваться данные по новым ЭСРП,
которые начинают действовать в рамках СМВ, и Роуминговым
лимитам ЭСРП.
В таблице ниже содержится описание требований к функциям
Интеграционного сервиса ИСМВ:
Таблица 18. Спецификация требований к функциям Интеграционного сервиса ИСМВ
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
4.2.1-1
Получение данных о
Должен быть реализован метод получения
транзакциях проезда
информации о транзакциях проезда, их
и корректировках
корректировке и фотографиях транспортных
средств, передаваемых от Операторов дорог
(СП).
Детальное описание данных, участвующих в
обмене в этом случае, содержится в разделе
68
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
настоящего ТЗ «Приложение 1. Формат обмена
даннымиª.
4.2.1-2
Получение данных
Должен быть реализован метод получения
об изменениях
изменений по Цветным спискам.
Цветных списков СП
Детальное описание данных, участвующих в
обмене в этом случае, содержится в разделе
настоящего ТЗ «Приложение 1. Формат обмена
даннымиª.
4.2.1-3
Передача полных
Должен быть реализован метод передачи полных
Цветных списков
Цветных списков для ПВП.
для ПВП
Детальное описание данных, участвующих в
обмене в этом случае, содержится в разделе
настоящего ТЗ «Приложение 1. Формат обмена
даннымиª.
4.2.1-4
Подписка на
Должен быть реализован метод подписки на
изменения в
изменения в Цветных списках для Оператора
Цветных списков
дороги (СП).
для Оператора дорог
Детальное описание данных, участвующих в
(СП)
обмене в этом случае, содержится в разделе
настоящего ТЗ «Приложение 1. Формат обмена
даннымиª.
69
Требования к функциям Личного кабинета ИСМВ
В Личном кабинете ИСМВ необходимо реализовать интерфейсы
пользователя, обеспечивающие поддержку выполнения следующих процессов:
1) Верификация Роуминговых транзакций
- процесс проверки
Контролёром
(сотрудником Эмитента ЭСРП) в Личном кабинете
ИСМВ данных по Роуминговым транзакциям, которые связаны с его
ЭСРП.
2) Оспаривание Роуминговых транзакций
- процесс корректировок
транзакций в ИСМВ и их согласования между Контролёром и
Регистратором
(сотрудником
организации-участника
СМВ,
информационная система которого зафиксировала Роуминговую
транзакцию).
В ИСМВ должна быть реализована поддержка следующих основных ролей
пользователей Системы, которые участвуют в процессах верификации и
оспаривания Роуминговых транзакций:
Контролёр;
Регистратор;
Администратор ИСМВ.
Подробное описание данных ролей содержится в разделе «Приложение 6.
Описание ролей пользователей ИСМВª настоящего документа.
В ИСМВ должна быть реализована поддержка выполнения следующего
алгоритма для процедур верификации и оспаривания транзакций:
1. Контролёр в своем Личном кабинете СП СМВ получает доступ к реестру
Роуминговых транзакций, которые имеют статус «Зарегистрирована в ИСМВª.
Данный реестр должен содержать все транзакции, которые были оплачены
посредством ЭСРП Эмитента, сотрудником которого проводится верификация.
70
В частности, данный реестр может содержать транзакции с признаком ошибки,
который присваивается, если в системе-источнике (СВП) для данной транзакции
производились какие-либо корректировки, или, если предварительные проверки
на этапе получения транзакции в ИСМВ выявили ошибки в применении тарифа
и расхождения в предклассификации/классификации/постклассификации ТС.
2.
Контролёр в течение регламентного срока, установленного для верификации и
оспаривания транзакций, должен иметь следующие возможности для действий в
системе:
2.1.изложить свои комментарии и обоснования для корректировки суммы
транзакции;
2.2.передать транзакцию на оспаривание Регистратору путем присвоения ей
специально предусмотренного для этого статуса транзакции;
2.3.отменить предложенное им оспаривание путем присвоения транзакции ей
специально предусмотренного для этого статуса.
3.
Регистратор в своем Личном кабинете получает доступ к реестру оспариваемых
транзакций, которые ему были переданы Контролером.
4.
Регистратор в течение регламентного срока, установленного для верификации и
оспаривания транзакций, должен иметь следующие возможности для действий в
системе:
4.1.принять версию транзакции, предложенную Контролером при оспаривании
транзакций
(если такой вариант был предложен в комментариях от
Контролёра), после чего транзакция должна быть передана Контролеру (на,
возможно, повторную верификацию и оспаривание);
4.2.скорректировать сумму транзакции вручную и присвоить ей специально
предусмотренный для этого случая статус, после чего транзакция должна
быть передана Контролёру
(на, возможно, повторную верификацию и
оспаривание);
4.3.отказать в корректировке с указанием причины в комментарии к статусу,
который должен быть предусмотрен специально для этого случая;
дополнительно отказ в корректировке может быть присвоен ИСМВ
71
автоматически по истечении регламентного срока корректировки
транзакции Регистратором. После этого транзакция должна быть передана
Контролеру (на, возможно, повторную верификацию и оспаривание).
5.
Контролер в своем Личном кабинете получает доступ к реестру оспариваемых
транзакций, которые ему были переданы Регистратором. Контролер должен
иметь возможность повторного оспаривания транзакций в течение
установленного регламентного срока.
6.
Администратор ЦМВ должен иметь права на окончательное разрешение
ситуации с оспариванием транзакции, если Контролер и Регистратор не могут
согласовать корректировку между собой. По результатам урегулирования
письменной претензии и на основании подтверждающих документов (например,
решение суда или других юридических документов) должен иметь возможность
производить корректировку транзакций с обязательным указанием основания
корректировки
(изменяется сумма, присваивается статус о согласовании и
указывается комментарий к статусу).
7.
Независимо от хода процедуры верификации и оспаривания транзакции, ее
изначальная сумма должна попадать в отчет сверки за тот период (передаваться
в Модуль формирования отчетов сверки), в котором она была зафиксирована в
СВП (источнике этой транзакции).
8.
Все согласованные между Контролером и Регистратором корректировки
транзакций, которые имеют специально предусмотренный для этого статус,
должны попадать в отчет сверки (передаваться в Модуль формирования отчетов
сверки) за тот период, в котором была окончательно согласована и принята
корректировка суммы транзакции.
Перечень и описание статусов транзакций в ИСМВ, которые должны быть
реализованы, содержатся в «Приложении 2. Статусы транзакций в ИСМВª к
настоящему документу.
72
В таблице ниже содержится описание требований к функциям Личного
кабинета ИСМВ:
Таблица 19. Спецификация требований к функциям Личного кабинета ИСМВ
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
4.2.2-1
Авторизация в
Должна быть реализована функция авторизации
Личном кабинете
в ИСМВ через Личный кабинет по паре
ИСМВ
параметров:
- логин;
- пароль.
Примечание: параметры доступа в ИСВМ
(логин-пароль) должны передаваться ЦМВ
организации-участнику СМВ в процессе её
подключения к СМВ.
4.2.2-2
Управление
Данный процесс поддерживается в ИСМВ для
реестром
реализации процедуры верификации
Роуминговых
Роуминговых транзакций Эмитентом. Для этого
транзакций (всех)
должны быть реализованы следующие функции:
- Просмотр реестра;
- Настройка фильтров для реестра;
- Сортировка реестра по столбцам;
- Выгрузка реестра в форматы MS Excel и PDF.
Примечание: дополнительные функции и
требования к их реализации для реестра
Роуминговых транзакций, отображаемого в
Личном кабинете, могут быть уточнены на этапе
Технического проектирования ИСВМ.
73
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
4.2.2-2.1
Просмотр реестра
Реестр для сотрудника Эмитента должен
Роуминговых
включать все Роуминговые транзакции, которые
транзакций по их
были оплачены с применением ЭСРП,
принадлежности к
принадлежащих этому Эмитенту. Реестр также
Эмитенту
должен автоматически обновляться в ИСМВ на
основании корректировок к транзакциям,
поступающих из СВП оператора дороги ,
зафиксировавшего Роуминговую транзакцию.
В реестре по столбцам должны отображаться все
основные атрибуты, которые хранятся по
Роуминговым транзакциям в ОХД ИСМВ:
- Дата и время транзакции;
- День/ночь;
- Идентификатор транзакции;
- Классификация ТС;
- ПВП проезда;
- Полоса;
- Сведения об ЭСРП;
- Статус транзакции;
- Стоимость проезда;
- Участок дороги;
- Ссылка на фото проезда;
- Атрибуты талона на въезд (в случае транзакции
на участке дороги с СВП закрытого типа);
- Атрибуты корректировки транзакции (в случае,
если транзакция корректировалась в СВП
74
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
Оператора, который ее зафиксировал);
- Признак ошибки в транзакции.
Для удобства просмотра реестра транзакций в
процессе их верификации в Личном кабинете СП
в ИСМВ должна быть реализована возможность
визуального выделения в реестре Роуминговых
транзакций со статусом проверки
«подозрительнаяª (этот статус присваивается по
результатам проверок в Модуле биллинга
ИСМВ).
Примечание: дополнительные требования к
форме реестра Роуминговых транзакций,
отображаемого в Личном кабинете, могут быть
уточнены на этапе Технического проектирования
ИСВМ.
4.2.2-2.2
Настройка фильтров
Должны быть реализованы возможности
для реестра
установки и снятия фильтров в реестре
Роуминговых
Роуминговых транзакций по следующим
транзакций
основным атрибутам:
- Дата и время транзакции;
- День/ночь;
- Классификация ТС;
- ПВП проезда;
- Полоса;
- Статус транзакции;
- Участок дороги;
75
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
- Признак ошибки в транзакции.
Примечание: дополнительные требования к
фильтрам для реестра Роуминговых транзакций,
отображаемого в Личном кабинете, могут быть
уточнены на этапе Технического проектирования
ИСВМ.
4.2.2-2.3
Сортировка реестра
Должны быть реализованы возможности
Роуминговых
сортировки по столбцам в реестре Роуминговых
транзакций
транзакций.
Примечание: детальные требования к сортировке
для реестра Роуминговых транзакций,
отображаемого в Личном кабинете, могут быть
уточнены на этапе Технического проектирования
ИСВМ.
4.2.2-2.4
Выгрузка реестра
Должна быть реализована возможность выгрузки
Роуминговых
реестра Роуминговых транзакций в форматы MS
транзакций в
Excel и PDF в том виде, в котором его настроил
форматы MS Excel и
пользователь ИСМВ с применением фильтров и
PDF
сортировки.
4.2.2-3
Корректировка
Данный процесс выполняется для целей
Роуминговых
верификации или согласования корректировок
транзакций
Роуминговых транзакций между Эмитентом и
организацией, которая зафиксировала
Роуминговую транзакцию на обслуживаемом ей
ПВП, в Личном кабинете ИСМВ.
76
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
По результатам верификации/согласования
корректировки пользователем ИСМВ, который
работает с реестром Роуминговых транзакций,
может быть принято решение необходимости
корректировки транзакции. Для этого должны
быть реализованы функции:
- Изменение транзакции;
- Сохранение или отмена изменений транзакции.
4.2.2-3.1
Изменение
Для изменения транзакции в ИСМВ должна быть
транзакции
реализована возможность выполнять следующие
действия:
1) Выбор транзакции в реестре Роуминговых
транзакций;
2) Переход к форме изменения транзакции;
3) Изменение/ввод пользователем значений
следующих основных атрибутов транзакций:
- Сумма корректировки;
- Статус корректировки;
- Комментарий к статусу корректировки.
3.1) Доступ на изменение к вышеуказанным
атрибутам транзакции должен зависеть от роли
пользователя:
3.1.1) Контролер должен иметь право изменять
только статус корректировки транзакции и
комментарий к статусу. Контролеру должны
быть доступны для присваивания следующие
77
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
статусы (прочие статусы ему доступны только в
режиме просмотра):
- Зарегистрирована в ИСМВ;
- Оспорена Контролером, рассматривается
Регистратором;
- Оспорена, направлена Администратору ЦМВ.
3.1.2) Регистратор имеет право изменять сумму
корректировки, согласно пожеланию, которое
излагается в комментарии к статусу,
присвоенному Контролером. Также Регистратор
должен иметь право вносить комментарий к
статусу, ему должны быть доступны для
изменения следующие статусы (прочие статусы
ему доступны только в режиме просмотра):
- Оспаривание согласовано Регистратором;
- Оспорена Контролером, отказано
Регистратором;
- Оспорена, направлена Администратору ЦМВ.
3.1.3) Администратор ЦМВ имеет право
изменять сумму, присваивать статус
«Оспаривание согласовано Регистраторомª и
комментарий к статусу по тем транзакциям,
которые направлены к нему в ситуациях, когда
Контролер и Регистратор не смогли между собой
согласовать корректировку, а согласовывали ее в
претензионном/судебном порядке (процесс - за
78
Автоматизируемый
Требования к выполнению процесса,
Номер
Процесс/Функция
требования к функциям процесса
процесса
рамками ИСМВ).
Примечание: статусы транзакций и правила для
них могут быть уточнены на этапе Технического
проектирования ИСМВ.
4.2.2-3.2
Сохранение или
Должна быть реализована функция
отмена изменений
подтверждения или отмены пользователем
транзакций
ИСМВ изменений, которые он внёс в
транзакцию.
При сохранении изменений в ИСМВ должны
автоматически фиксироваться и храниться
следующие атрибуты:
- Дата и время корректировки;
- Автор и источник корректировки (СВП-2, СВП-
3, ИСМВ; пользователь, выполнивший
корректировку);
- История корректировок транзакции.
4.2.2-4
Согласование
Для согласования корректировок по
корректировок по
Роуминговым транзакциям должны быть
Роуминговым
реализованы следующие функции:
транзакциям
- Инициирование передачи корректировки
транзакции в ИС, откуда изначально была
получена эта транзакция (СВП).
- Управление реестром транзакций, по которым
необходимо выполнить согласование
корректировок в процессе /согласования
79
содержание .. 1 2 3 ..