Ошибки фис гиа и приема

admin	#1 Оставлено : 4 августа 2018 г. 12:21:12(UTC)
Статус: Администрация Группы: Administrators Зарегистрирован: 27.07.2018(UTC) Сообщений: 1,474 Сказал(а) «Спасибо»: 2 раз Поблагодарили: 10 раз в 6 постах	Номер ошибки: 138 Сообщение об ошибке: В формах обучения и источниках финансирования указан несуществующий конкурс (UID: {0}) Способы устранения: В Формах обучения и источниках финансирования (FinSourceAndEduForms) указан UID конкурсной группы (CompetitiveGroupID), не указанный в элементе FinSourceAndEduForms (конкурсные группы заявления)

Ludmila Tihonova	#2 Оставлено : 15 июня 2019 г. 7:20:40(UTC)
Статус: Advanced Member Группы: Registered Зарегистрирован: 29.07.2018(UTC) Сообщений: 661 Сказал(а) «Спасибо»: 41 раз Поблагодарили: 35 раз в 34 постах	Ответы от коллег в контексте взаимодействия ФИС с 1С:Университет: Виталий: Коллеги, добрый день! Подскажите, пожалуйста, по выгрузке в ФИС. Пишет: «В формах обучения и источниках финансирования указан несуществующий конкурс». Посмотрел, действительно UID конкурса отличается от того что в ФИСе двумя последними цифрами. Как такое могло произойти, и как бороться? Исправить в ФИС или в заявлении ручками на тот UID что в ФИС? Заранее спасибо. Владимир: Как такое могло произойти — вопрос хороший. Видимо конкурс перенастраивали после выгрузки. Проверьте все ли настройки конкурса совпадают в 1с и в фис. Если все совпадает и вы точно уверены, что это именно тот конкурс, тогда можно его уид поправить в фис. В заявлении точно не стоит править. Ведь все заявления с таким уидом будут генерироваться.

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Дано: 1С:Университет ПРОФ.
Вопрос: Что делать, если абитуриент сдает вступительные испытания, а ФИС ГИА и приема сообщает, что он не прошел проверку ЕГЭ и отправляет его в раздел «Не прошедшие проверку»?

Ответ: При выгрузке в ФИС не указывается, сдает ли абитуриент ЕГЭ или внутренние тесты.
Поэтому, т.к. результатов тестов в базе еще нет, то заявления выгружаются без результатов тестов, а при необнаружении результатов по какому-либо предмету ФИС пытается найти по нему ЕГЭ.
Когда в базе появятся результаты вступительных испытаний, необходимо будет перевыгрузить заявления таких людей. Для этого можно использовать отбор «Установить дополнительный отбор по наличию результатов вступительных испытаний» в обработке выгрузки в ФИС.
Перевыгружать их можно двумя способами:
1. Либо поставив галочку «Удалить заявления в ФИС перед выгрузкой» — в этом случае будет послан запрос на удаление выгружаемых заявлений из ФИС.
2. Либо сначала поставив галочку «Выгружать поданные заявления со статусом «Новое»», выгрузив пакет с заявлениями, затем снять галочку и повторно сформировав и выгрузив пакет с заявлениями.
Фис рекомендует использовать второй вариант.
Т.к. невозможно вносить корректировки в принятые заявления, не забывайте периодически удалять заявления.

Как не надо делать федеральные информационные системы

Данная статья будет интересна узкому кругу читателей Хабра — разработчиков федеральных информационных систем и широкому — тех, кому с этими системами уже приходилось, приходится или придется взаимодействовать в будущем.
Повествование будет вестись на примере ФИС ГИА и приема (это название присвоено Д. Медведевым 31.08.2013 г., предыдущие полтора года система была известна под именем, данным В. Путиным — ФИС ЕГЭ и приема).

Что это вообще такое и кому оно нужно?

Федеральная информационная система обеспечения проведения государственной итоговой аттестации обучающихся и приема граждан в образовательные организации (полное название по ссылке) — система, созданная в интересах Рособрнадзора, в которую вузы и ссузы уже 3 года обязаны заносить сведения о ходе приёмной кампании, включая персональные данные всех абитуриентов. А именно, до начала приема туда в определенном формате передаются количество мест, перечни вступительных испытаний, разрешенные льготы, а во время — данные о заявлениях абитуриентов, включая ФИО и реквизиты паспорта, практически в режиме реального времени.

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

Взаимодействие образовательных учреждений с ФИС

Все учреждения высшего и среднего профессионального образования обязаны ежедневно передавать в ФИС сведения о ходе приема. Для этого предусмотрен как веб-интерфейс ввода и просмотра данных, так и сервис автоматизированного взаимодействия для пакетной передачи в XML-формате. Теоретически всё красиво, но есть толстые нюансы. Первый — это скорость взаимодействия: в ручном режиме на ввод одного заявления в часы пиковых нагрузок уходит до 20 минут, а в автоматизированном пакеты могут ждать обработки в очереди сутками. Второй — ошибки в работе программного обеспечения, порождающие противоречия в данных. Но обо всём по порядку.

Проектирование модели данных

В предметной области приемной кампании один абитуриент может подать до трех заявлений в вуз. В случае передачи данных в XML различные сущности представляются в виде элементов дерева. Как бы вы решили задачу представления заявлений в XML? Очевидно, заявления привязаны к абитуриенту и логично разместить сведения о личности абитуриента в элементе более высокого уровня, а о поданных им заявлениях — во вложенных элементах. Однако разработчики ФИС поступили наоборот: сведения об абитуриенте повторяются в каждом заявлении и даже могут противоречить друг другу, и тогда в веб-интерфейсе появляется несколько строчек с одинаковыми ФИО, но разными, например, паспортными данными. При этом ссылки из всех таких строк ведут в одну и ту же карточку, в которой отображается только один случайный паспорт из нескольких противоречивых.

Еще из замечательного. Понятно, что в XML производится только обмен данными, а внутреннее представление в системе является всё-таки реляционным и хранится в приличной СУБД. И тогда возникает очень хорошая идея — добавить в протокол обмена первичные ключи сущностей, используемые в системах вузов, являющихся источниками данных. Ведь это должно упростить выявление новых сущностей и обновление старых. Но следует ли исходить из того, что все клиентские системы имеют аналогичную модель данных и реляционная ли она в них вообще? Наверняка вузовским программистам клиентов обмена данными забавно будет столкнуться с необходимостью генерировать уникальный и неизменный идентификатор там, где его отродясь не было, или опытным путем наткнуться на ошибку, при которой идентификатор аттестата и, например, диплома олимпиады не могут совпадать (видимо, в ФИС все документы хранятся в одной таблице, но где это отражено в документации?)

Документация

Грамотная документация при публикации в продакшн системы, с которой должны стыковаться сотни и тысячи разношерстных систем поменьше — залог успеха. Грустно, что разработчики ФИС не смогли решить эту задачу даже за 3 года, хотя некоторый прогресс всё-таки имеется. Опубликованная структура XML в виде PDF-документа и XSD-схемы, безусловно, необходима. Но важно хотя бы проверить, чтобы XSD была, во-первых, валидной, а во-вторых — не конфликтовала с эталонным XML-документом. Иначе сотни сторонних разработчиков будут исправлять корявые regex-ы и досадные length=«50» вместо maxLength=«50» вместо тех, кому это положено.
Кроме того, формального описания протокола обмена категорически недостаточно, ведь в случае сложной структуры данных система будет принимать не любой валидный пакет, а только тот, который удовлетворяет ряду дополнительных проверок на адекватность. Один из примеров с внешними ключами приведен выше.

Ограничения и проверки при взаимодействии с внешними клиентами

Вообще, не перейти тонкую грань между необходимыми проверками и избыточными ограничениями, не пропускающими корректные данные — почти как удержаться на лезвии ножа. И главное здесь — доскональное понимание предметной области перед началом разработки. В частности, разработчики ФИСа в этом году начали резать вполне допустимый в ряде случаев прием заявлений на нулевые квоты. Когда стоит цель сбора информации, лучше разрешить загрузку некорректных на первый взгляд данных для последующего анализа, а отсекать только заведомо неполные.

Ошибки в системе и рекомендации разработчикам сопрягаемых систем

ФИС в частности и, подозреваю, государственные системы вообще — замечательный образец нестабильных «партнеров» для оттачивания навыков взаимодействия с удаленными системами, когда следует проверять абсолютно все. Например, отправлен XML в HTTP-запросе и в ответ ожидается другой XML, но:

1. Может просто оборваться сетевое соединение.
2. Может случиться таймаут и его, кстати, лучше заранее сделать разумным, так как иначе ожидание ответа может растянуться на часы.
3. В ответ может придти не XML вовсе, а что угодно.
4. Может придти XML, не соответствующий заявленной разработчиком схеме.
5. Придет XML, но данные в нем будут противоречивы. Пример — в запросе отправлено 100 объектов для импорта, в ответе ожидается количество успешно импортированных и перечень незагруженных из-за ошибок. На поверку же в ответе оказывается всего 83 объекта, а где искать остальные 17 и какие в итоге вообще загружены — остается загадкой.

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

Организация подключения к системе и защита ПДн

Для тех, кто дочитал до этого абзаца — самое интересное. ФИС ГИА и приема расположена в закрытой сети Федерального центра тестирования, к которой вузы подключаются через VPN-клиенты ViPNET. Кроме того, за приличные деньги навязывается некое уникальное решение малоизвестной фирмы-монополиста для фильтрации данных на стороне клиента, «чтобы не выкачать из системы с персональными данными миллионов граждан лишнего». Объяснение, почему эта фильтрация должна производиться у каждого клиента, а не единственный раз на серверной стороне, отсутствует. По косвенным признакам данное уникальное решение является всего лишь прокси-сервером, фильтрующим допустимые URL при работе с сервером ФИС.

Однако недавно пытливые умы заметили, что если в просмотре результатов импорта пакетов в веб-интерфейсе случайно (или намеренно) указать другой идентификатор пакета, то он откроется! И не только откроется, а еще и позволит скачать XML-файл со всеми данными всех абитуриентов, включая паспорта, данные о предыдущем образовании, сведения о льготах, в т.ч. медицинских, и т.д. Таким образом, любой пользователь, имеющий доступ к ФИС, имеет возможность получить простым перебором данные значительной части абитуриентов за последние 3 года.

Резюме

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

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

Удачи вам!

28 июня 2021 года вышла новая версия обработки «Выгрузка заявлений абитуриентов в ФИС».

В новой версии обработки:

1. Выполнена адаптация обработки в части выгрузки заявлений поступающих в соответствии со новой спецификацией ФИС ГИА и Приема версии 4.4.2:

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

1.2. Добавлена проверка заполнения поля «Выдавшая организация» («DocumentOrganization») в документе «Справка об установлении инвалидности» («DisabilityDocument»).

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

1.4. Добавлена выгрузка необязательного поля СНИЛС («SNILS») поступающего («Entrant»).

2. При выгрузке заявлений поступающих в ФИС наблюдается нестабильное поведение ФИС ГИА и Приема при валидации файлов, сформированных в соответствии со спецификацией 4.4.2.

2.1. В некоторых случаях сервер взаимодействия с ФИС ГИА и Приема требует заполнения тегов «ReleaseCountryID», «ReleasePlace». Без них данные не загружаются в ФИС ГИА и Приема (возникает ошибка Ошибка валидации XML. Line: xxx — Position: x — The element ‘IdentityDocument’ has incomplete content. List of possible elements expected: ‘ReleaseCountryID, ReleasePlace’).

2.2. В некоторых случаях сервер взаимодействия с ФИС ГИА и Приема требует отсутствия тегов «ReleaseCountryID», «ReleasePlace». С ними данные не загружаются в ФИС ГИА и Приема (возникает ошибка Ошибка валидации XML. Line: xxx — Position: x — The element ‘IdentityDocument’ has invalid child element ‘ReleaseCountryID’. List of possible elements expected: ‘GenderID, OriginalReceivedDate, BirthPlace’).

2.3. На момент выпуска обработки установить закономерность, в каких случаях требуется заполнение тегов «ReleaseCountryID»,»ReleasePlace», а в каких не требуется — не удалось. По этому вопросу ведется взаимодействие с линией консультационной поддержки ФИС ГИА и приема.

2.4. В связи с пунктами 2.1-2.3 на вкладке «Настройки» обработки выгрузки в ФИС ГИА и приема добавлен блок опций «Совместимость со старой спецификацией ФИС 4.4.1», при включении которых новые реквизиты выгружаться не будут. Список опций:

• Не выгружать выдавшую страну и место выдачи в документах, удостоверяющих личность (режим совместимости со спецификацией 4.4.1);
• Не выгружать СНИЛС (режим совместимости со спецификацией 4.4.1);
• Не выгружать статус соотечественника в документах соотечественников (режим совместимости со спецификацией 4.4.1).

В случае возникновения ошибок вида 2.2 (Ошибка валидации XML. Line: xxx — Position: x — The element ‘IdentityDocument’ has invalid child element ‘ReleaseCountryID’. List of possible elements expected: ‘GenderID, OriginalReceivedDate, BirthPlace’) Вы можете установить флаги совместимости, но есть вероятность возникновения ошибок вида 2.1 (Ошибка валидации XML. Line: xxx — Position: x — The element ‘IdentityDocument’ has incomplete content. List of possible elements expected: ‘ReleaseCountryID, ReleasePlace’).

2.5. Предполагаемый верный сценарий работы — с выключенными опциями из пункта 2.4. При таком сценарии данные в некоторых случаях выгружаются успешно.

3. Исправлена ошибка проверки настройки соответствия направления подготовки при выгрузке заявления для конкурсов на УГС.

4. Исправлена ошибка неправильного формирования идентификатора конкурса при выгрузке заявления/приказа, что приводило к ошибке не найденного идентификатора при загрузке заявления/приказа в ФИС.

5. Исправлена ошибка-исключение выгрузки файлов при включенной опции «Добавлять уровень бюджета в наименование и идентификатор конкурса».

Новая версия обработки «Выгрузка заявлений абитуриентов в ФИС» доступна для скачивания на https://releases.1c.ru/ в разделе релиза 2.2.4.1 «1С:Университет ПРОФ» и 20.23.1 «1С:Университет».