Методы интеграции специализированных информационных систем

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ 
«БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ
ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ»
(НИУ «БелГУ»)



ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК
КАФЕДРА ИНФОРМАЦИОННЫХ И РОБОТОТЕХНИЧЕСКИХ СИСТЕМ




Методы интеграции специализированных информационных систем


Магистерская диссертация 
обучающегося по направлению подготовки
09.04.02 Информационные системы и технологии 
очной формы обучения
группы 07001635 
Дегтяревой Анастасии Михайловны
(Фамилия, имя, отчество)







Научный руководитель
доц., Гахов Роман Павеласович



Рецензент






БЕЛГОРОД 2018


        Содержание
      
ВВЕДЕНИЕ	3
1. Анализ существующих подходов интеграции информационных систем	6
1.1 Интеграция на уровне данных	6
1.2 Интеграция с помощью корпоративных приложений	7
1.3 Интеграция с помощью web-служб и web-API	8
2. Проектирование интеграции информационных систем	11
2.1 Информационная модель интеграции систем	11
2.2 Проектирование разделов интеграции систем	15
2.3 Проектирование интеграции информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-API	20
3. Программная реализация интеграции информационных систем	30
3.1 Разработка в ПП «Парус 8»	30
3.2 Разработка web-API	37
      



      ВВЕДЕНИЕ

      В настоящий момент взаимодействие информационных систем друг с другом является основой для существования и успешного развития компаний. Для пользователей интеграция систем решаем проблемы, связанные с приемом и передачей данных, со временем обработки информации, с доступностью к данным и д.р. Информационные системы стали неотъемлемой частью современной экономики. К интеграции систем относится сбор различных подсистем в единое целое с физической или функциональной точки зрения. Глобализация вопроса о передаче данных привела к вынужденному обмену информацией между системами.
      Научная новизна заключается в модернизации метода интеграции специализированных информационных систем «Виртуальная школа» и программного продукта (ПП) «Парус 8». 
      Объектом исследования выбран процесс учета оплаты питания в образовательных учреждениях. Предметом исследования являются методы и средства интеграции информационных систем.
      Цель магистерской диссертации – совершенствование учета оплаты школьного питания за счет его автоматизации путем интеграции специализированной информационной системы образовательных услуг (ИСОУ) «Виртуальная школа» и программного продукта (ПП) «Парус 8».
      К задачам магистерской диссертации относится:
      * анализ методов интеграции информационных систем;
      * проектирование интеграции специализированных информационных систем;
      * разработка интеграции специализированных информационных систем.
      На сегодняшний момент существуют различные методы интеграции информационных систем. Для начала необходимо рассмотреть факторы, влияющие на интеграцию:
      Безопасность – если данные передаются не из рук в руки, а передаются по каналам связи, вопрос о шифровании данных становится более актуальным.
      Мобильность – пользователям необходимо реагировать и передавать данные мгновенно, за кроткий промежуток времени, пользователь должен принять информацию, обработать и отправить ответ.
      Непрерывность цикла работы – синхронизация и обновление систем не должно влиять на работу пользователей и функционирование системы в целом.
      Высокая загруженность – количество пользователей, работающих в системе одновременно, поток обрабатываемой и передаваемой информации.
      Интерактивность – пользователь системы всегда ожидает от системы большей скорости реагирования, быстродействия и оперативности обработки данных.
      Межсистемная интеграция – взаимосвязь между системами партнеров, клиентов, поставщиков и т.д .
      При решении задачи, связанной с межсистемной интеграцией сложность заключается в следующих параметрах:
      Концептуальные различия систем. Разработчики систем на этапе проектирование изначально использовали разные решения.
      Технологические различия систем. Использование разных форматов данных, связей взаимодействия и сервисов.
      Для решения сложных вопрос интеграции необходимо использовать следующий набор средств:
      Стандартизация – использовать международные, государственные, отраслевые стандарты разработки.
      Интеграция на уровне брокеров. Выбор этого средства имеет преимущество в том, что можно разработать дополнительный блок, к которому могут обращаться все системы и разными способами, например через базу данных и RPC. Недостатком такого средства является сложность и трудоемкость разработки.
      Интеграция на уровне данных – возможность, при которой системы могут обращаться в одну базу данных. Преимущества такого средства заключаются в низкой стоимости интеграции. К недостаткам следует отнести тот факт, что если изменится структура базы данных, необходимо будет переписывать программный код всех процедур, приложений и отчетов.
      Интеграция с помощью сервисов – современный и быстро совершенствующий подход интеграции систем. К преимуществам можно отнести взаимодействие интерфейсов и форматов данных, что способствует быстрой передачи данных.
      При разработке интеграции информационной системы образовательных услуг (ИСОУ) «Виртуальная школа» и программного продукта (ПП) «Парус Бюджет 8» используется интеграция при помощи web- API. Управление информацией сервиса полностью основывается на протоколе передачи данных HTTP. 
      


      1. Анализ существующих подходов для интеграции информационных систем
      
      Интеграция – это взаимодействие разных систем, их блоков, передача данных в разных форматах. Интеграция может проходить на уровне данных, сетевых устройств, программных приложений, пользовательских интерфейсов и различных сервисов.
      Рассматривая вопрос о межсистемной интеграции самой главной задачей становится найти оптимальный способ интеграции. Чистая система интеграции – трудоемкий и дорогостоящий процесс. Затраты на такую интеграцию увеличиваются за счет сопровождения чистой системы.  Поэтому, для выбора оптимального способа интеграции необходимо рассмотреть возможные варианты и оценить их преимущества и недостатки.
      
      1.1 Интеграция на уровне данных
      При интеграции на уровне данных возникает много вопросов по типам и форматам данных. Преобразование разновидной информации доставляет много проблем со сбором данных, их структурированием, обработкой, хранением и передачей. 
      Для интеграции на уровне данных, как правило используют стандартные протоколы и интерфейсы, такие как SQL.
      Преимущества интеграции на уровне данных заключаются в низкой стоимости интеграции. К недостаткам следует отнести тот факт, что если изменится структура базы данных, необходимо будет переписывать программный код всех процедур, приложений и отчетов.
      Самым простым примером, где используется такой вид интеграции – системы электронного документооборота, CRM и ERP-системы. Такие системы используют, изменяют информацию друг друга, как раз за счет интеграции данных.
      
      1.2 Интеграция с помощью корпоративных приложений 
      Интеграция корпоративных приложений (EAI) это использование технологий и функций по всему предприятию, возможность интеграции программных приложений и аппаратных систем. Многие несвободные и открытые проекты обеспечивают поддержку решения EAI. 
      Развивающиеся связующие технологии EAI включают веб-службы интеграции, сервис ориентированные архитектуры, интеграции контента и бизнес-процессов. 
      Взаимосвязь между приложениями предприятия (EA), такие как управления отношениями с клиентами (CRM), управление цепочками поставок (SCM) и бизнес-аналитики не автоматизированы. Таким образом EAs не разделяют общие данные или бизнес-правила. EAI позволяет упростить и автоматизировать бизнес-процессы без применения чрезмерных изменений структуры приложения или данных.
      При EAI возникают проблемы с несовместимостью операционных систем, архитектур баз данных и/или языков программирования, а также другие ситуации, где унаследованных систем больше не поддерживаются производителем.
      Эти проблемы возникают, если следующие вопросы решаются с помощью EAI:
      Интеграция данных - обеспечивает последовательную информацию между различными системами;
      Независимость поставщиков - бизнес-политики или правила, касающиеся конкретные бизнес-приложения не должны осуществляться заново при замене части приложений.
      Использование EAI при интеграции систем и/или приложений — это создание «брокера» информации, блок, к которому могут обращаться все системы и разными способами, например через базу данных и RPC. Недостатком такого средства является сложность и трудоемкость разработки.
      1.3 Интеграция с помощью web-служб и web-API
      Для начала необходимо определиться чем web-API отличается от других web-служб. Все веб-службы являются API-интерфейсами, но не все API-интерфейсы являются веб-службами. Web-API и веб-службы часто путаются друг с другом, однако web-API - это эволюция веб-сервисов. Оба облегчают передачу информации, но web-API более динамичны, чем веб-сервисы. 
      По определению, веб-служба представляет собой программное обеспечение, которое доступно с помощью браузера. Клиент вызывает веб-службу, отправляя запрос, как правило в форме XML-сообщения, и служба отправляет ответ, также в формате XML. Связь между клиентом и веб-службой обычно создается с помощью HTTP. 
      Типичный веб-API определяет, как программные компоненты должны взаимодействовать друг с другом с использованием протокола HTTP. Клиенту не нужно знать, какую процедуру вызывать на сервере. Вместо этого он использует набор команд, которые встроены в HTTP, и когда команда поступает с другого конца, система получает информацию о том, что с ней делать. Главным преимуществом веб-API является гибкость. Клиентская система и обслуживающая система («поставщик») настолько независимы друг от друга, что каждый из них может использовать разные языки (Java, Python, Ruby и т. Д.). Для своей части общая реализация. Кроме того, полезная нагрузка данных может быть нескольких типов, таких как JSON или XML. API-интерфейсы RESTful чаще всего используют протокол HTTP.
      API определяет, как компоненты разных систем должны взаимодействовать друг с другом. API представляет собой набор протоколов и подпрограмм; ответы, как правило, возвращаются как данные JSON или XML. API могут использовать какой-либо протокол связи и не ограничиваться только им. тем же способом, что и веб-служба.
      Веб-API и веб-службы служат средством интеграции систем. Оба поддерживают данные на основе XML, но JSON – это более распространенный текстовый формат обмена данными для веб-API. При сравнении веб-сервисов с веб-API значимость заключается в объеме работы, которую должны обработать сервисы. Процессы обработки данных называют сериализацией и десериализацией. Сериализация и десериализация JSON в сценарии веб-API обычно требует гораздо меньше работы, что, в свою очередь, приравнивается к лучшей производительности и меньшему количеству циклов вычисления. Это одна из причин, почему веб-API отлично подходят для передачи информации на мобильных устройствах и планшетах; в отличие от настольных компьютеров и служб, где они имеют ограниченные среды обработки. Веб-службы облегчают взаимодействие между двумя системами и почти всегда зависят от интерфейса, подобного XML-RPC. SOAP - преемник XML-RPC, определяет упомянутый выше обмен на основе XML и более связан с архитектурой клиент - сервер.
      На данный момент веб-сервисы являются сервисом интеграции от одного устройства к другому; они обмениваются данными через Интернет и оптимизированы для связи между машинами, что означает, что машиночитаемые файлы и форматы (например, XML) легко переносятся. API-интерфейсы представляют собой программные интерфейсы с абстрактным набором функций для доступа к веб-приложениям.
      Рассмотрев различные факторы, влияющие на выбор средства интеграции и изучив возможные методы интеграции специализированных информационных систем, можно сделать вывод, что для достижения поставленной цели в работе необходимо рассматривать интеграцию с помощью web-API. Выбор данного метода обеспечивает доступную и быструю разработку системы интеграции, а также обслуживание с использованием минимальных, как трудовых, так и финансовых затрат, за счет использования в разработке простого интерфейса управления информацией без использования дополнительных внутренних прослоек.

      2. Проектирование интеграции информационных систем

      2.1 Информационная модель интеграции систем
      Перед тем, как приступить к проектированию интеграции специализированных информационных систем ИСОУ «Виртуальная школа» и «Парус 8» необходимо построить информационную модель «Как должно быть». В ПП «Парус 8» необходимо разработать подсистему «Виртуальная школа», с которой будет осуществляться интеграция данных. Информационная модель подсистемы «Виртуальная школа» выглядит следующим образом (рисунок 1):
      
        
      Рисунок – Подсистема «Виртуальная школа»
      
      Подсистема «Виртуальная школа» имеет следующие входные данные: регламентированное техническое задание; данные о студентах, данные о заказах питания и данные о типах питания.
      К выходным параметрам подсистемы относится: квитанции для оплаты и информация о движении денежных средств.
      Управление включает в себя следующее: нормативные документы Белгородской области, нормативные документы управления образования администрации районов Белгородской области, стандарты системы «Сбербанк» и технологии API. 
      К механизму, в подсистеме «Виртуальная школа» относится: экспер-аналитик компании «Парусник-Белгород», программисты компании «Парусник-Белгород», сотрудники компании «Сбербанк» и «ФИТ».
      Декомпозиция подсистемы «Виртуальная школа» выглядит следующим образом (рисунок 2):
      
        
      Рисунок – Декомпозиция подсистемы «Виртуальная школа»
      
      Декомпозиция подсистемы имеет следующие процессы: «Анализ, разработка и тестирование», «ПП «Парус 8» и «Сервис API для обмена данными».
      Процесс «Анализ, разработка и тестирование» имеет входные параметры: «Технические задания» и «Информация о тестировании».
      К выходным параметрам этого процесса относится «ТЗ на разработку» и «Контроль и координация выполнения работ».
      К управлению в процессе «Анализ и тестирование» относятся нормативные документы Белгородской области, нормативные документы управления образования администрации районов Белгородской области и стандарты системы «Сбербанк».
      Механизмом в процессе выступает экспер-аналитик компании «Парусник-Белгород» и сотрудники компании «Сбербанк».
      Процесс «ПП «Парус 8» имеет следующие входные параметры: «ТЗ на разработку», «Информация об обмене» и «Данные для хранения».
      Выходными данными этого процесса являются: «Данные для тестирования», «Пользовательские задания» и «Данные о балансе для передачи».
      В качестве управления в данном процессе выступает «Контроль и координация выполнения работ», стандарты API и системы «Сбербанк».
      Механизмом в процессе выступают программисты компании «Парусник-Белгород».
      Процесс «ПП «Парус 8» выглядит следующим образом (рисунок ):
        
      Рисунок – Процесс «ПП «Парус 8»
      
      Декомпозиция процесса «ПП «Парус 8» включает в себя три процесса: «Разработка», «Заказы питания» и «Личные карточки».
      Процесс «Разработка» имеет следующие входные потоки: «ТЗ на разработку» и «Ин-ция об обмене». К выходным потокам в процессе «Разработка» относится: «Пользовательские задания», «Ин-ция о тестировании» и «Сопровождение ПП».Упавлением в этом процеесе выступает  «Контроль и координация выполнения работ», а механизмом «Программисты».
      Процесс «Заказы питания» содержит следующие входные потоки «Данные для хранения», «Сопровождение ПП» и «Данные об учащихся». К выходным потокам этого процесса относится «Данные о балансе для передачи». Упавлением в этом процеесе выступает  «Контроль и координация выполнения работ» и «Стандарты API», а механизмом «Программисты».
      Процесс «Личные карточки» имеет следующие входные параметры: «ТЗ на разработку», «Информация об обмене» и «Данные для хранения».
      Выходными данными этого процесса являются: «Данные для хранения», «Сопровождение ПП». В качестве управления в данном процессе выступает «Контроль и координация выполнения работ» и «Стандарты API». Механизмом в процессе выступают программисты компании «Парусник-Белгород».
      Таким образом, была изложена модель «Как должно быть» подсистемы «Виртуальная школа».
      
      2.2 Проектирование разделов интеграции систем
      Согласно технического задания заказчика (Приложение ) необходимо разработать следующее:
      А) Раздел «Заказы питания», который должен отражать информацию из штатного раздела «Личные карточки» в частности ФИО, лицевой счет, дату начала и дату конца действия, подведомственное учреждение и класс, в котором числится ученик.  Также, раздел «Заказы питания» должен хранить информацию по типам питания, начислению и списанию денежных средств и оплатах. 
      Б) Раздел «Журнал взаимодействия» для хранения и обработки данных в результате интеграции с «ИСОУ «Виртуальная школа» с помощью API сервиса.
      В) Интеграцию специализированных информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API.
      
      2.2.1 Проектирование раздела «Заказы питания»
Описание раздела. 
      Раздел «Заказы питания» должен вызываться в меню «Учет» и иметь каталожную структуру, делиться по учреждениям.
      Заголовок раздела должен иметь следующие поля:
      * «Личная карточка» - ссылка на раздел «Личные карточки»;
      *  «ФИО» - заполняется автоматически из полей Фамилия, Имя, Отчество раздела «Личные карточки» по связи с номером личной карточки;
      * «Номер лицевого счета» - заполняется автоматически из поля «Лицевой счет» раздела «Личные карточки» по связи с номером личной карточки;
      * «Учреждение» - ссылка на заголовок раздела «Учреждения»;
      * «Класс» - ссылка на спецификацию «Группы» раздела «Учреждения»;
      * «Региональный бюджет» - числовое поле, рассчитывается путем сложения значений поля «Региональный бюджет» спецификации «Питание»;
      * «Муниципальный бюджет» - числовое поле, рассчитывается путем сложения значений поля «Региональный бюджет» спецификации «Питание»;
      * «Родительская оплата» - числовое поле, рассчитывается путем сложения значений поля «Родительская оплата» спецификации «Питание».
      Спецификация раздела «Заказы питания» должна имеет четыре вкладки: «Питание», «Начисления», «Оплаты» и «Расчет за месяц».
      Спецификация «Питание» должна состоять из следующих полей:
      * «Дата» - поле формата ДД.ММ.ГГГГ;
      * «Наименование блюда» - значение соответствует полю «Примечание» из доп.словаря «Виды блюд»;
      * «Тип питания» - значение из доп.свойства «Тип питания» соответствующего «Вида блюда»;
      * «Региональный бюджет» - значение из доп.свойства «Региональный бюджет» соответствующего «Вида блюда»;
      * «Муниципальный бюджет» - значение из доп.свойства «Муниципальный бюджет» соответствующего «Вида блюда»;
      * «Родительская оплата» - значение из доп.свойства «Родительская оплата» соответствующего «Вида блюда».
      В спецификации «Питание» должны быть стандартные действия: «Добавить», «Изменить», «Удалить».
      Спецификация «Начисления» формируется на основании спецификации «Питание», должна состоять из следующих полей:
      * «Наименование» - поле соответствует полю «Наименование» спецификации «Питание»;
      * «Месяц» - строковое поле, заполняется из параметра Расчетный период;
      * «Год» - числовое поле, заполняется из параметра Расчетный период;
      * «Количество» - числовое поле, значение поля соответствует количеству записей данного наименования в спецификации «Питание» в текущем расчетном периоде;
      * «Региональный бюджет» - числовое поле, поле вычисляется путем суммирования значений поля «Региональный бюджет» в спецификации «Питание» да данному наименованию в данном расчетном периоде;
      * «Муниципальный бюджет» - числовое поле, поле вычисляется путем суммирования значений поля «Муниципальный бюджет» в спецификации «Питание» да данному наименованию в данном расчетном периоде;
      * «Родительская оплата» - числовое поле, поле вычисляется путем суммирования значений поля «Родительская оплата» в спецификации «Питание» да данному наименованию в данном расчетном периоде.
      В спецификации «Начисления» стандартные действия отсутствуют. 
      Спецификация «Оплаты» должна имеет следующие поля: «Год», «Месяц», «Сумма», «Дата платежа», «Тип оплаты», «Погашение задолженности», «Документ-основание», «Тип документа-основания», «Номер документа», «Дата документа-основания», «Примечание». 
      В спецификации «Оплаты» должны быть стандартные действия: «Добавить», «Изменить», «Удалить».
      Сумма в поле «Входящий остаток» - поле заполняется автоматически, путем переноса значения из поля «Исходящий остаток» прошлого периода. 
      Сумма в поле «Начислено» - поле заполняется автоматически из поля «Начислено» (Родительская оплата) спецификации «Начисления»;
      Сумма в поле «Оплачено» - поле заполняется автоматически, путем сложения значений поля «Сумма» в спецификации «Оплаты», у которых Тип оплаты - Оплата.
      Сумма в поле «Возвращено» - поле заполняется автоматически, путем сложения значений поля «Сумма» в спецификации «Оплаты», у которых Тип оплаты - Возврат.
      Сумма в поле «Исходящий остаток» - значение поля рассчитывается автоматически путем вычитания значения  из поля «Оплачено» значение поля «Начислено».
      В спецификации «Расчет за месяц» стандартные действия отсутствуют. 
      Действия в разделе.
      Заголовок документа должен содержать стандартные действия «Добавить», «Размножить», «Исправить», «Удалить».
      Данные в разделе должны отображаться в рамках одного периода (месяца). Создать действие «Сменить расчетный период».
      При выполнении действия отображается форма для задания нового расчетного периода (месяц, год). После выбора периода и нажатия ОК изменяются данные, отображаемые в спецификациях "Начисления" и "Оплаты".
      В разделе «Заказы питания» отображаются только те записи, в личных карточках которых срок действия включает в себя хотя бы один день текущего расчетного периода.

       2.2.2 Проектирование раздела «Журнал взаимодействия»
      Раздел должен вызываться в меню «Учет», иметь каталожную структуру и делиться по учреждениям.
      Заголовок раздела должен содержать следующие поля:
      * «Пользователь» - учетное имя пользователя, по которым выполняется пользовательское задание;
      * «Вид операции» - текстовое поле, может принимать следующие значения: «Получение данных о заказах питания», «Получение данных об учениках», «Передача данных по оплатам», «Передача квитанций», «Получение данных о типах питания»;
      * «Идентификатор документа» - числовое поле, значение номера обработки данных на сервисе;
      * «Дата начала действия» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, дата и время запуска пользовательского задания;
      * «Дата окончания действия» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, дата и время окончания работы пользовательского задания;
      * «Количество сообщений» - числовое поле, для записи количества сообщений возникших при передаче данных с сервиса;
      * «Количество ошибок» - числовое поле, для записи количества ошибок возникших при передаче данных с сервиса;
      * «Время выполнения» - поле в формате ЧЧ.ММ.СС, для записи фактического времени выполнения пользовательского задания;
      * «Дата документа» - поле в формате ДД.ММ.ГГГГ ЧЧ.ММ.СС, для записи времени, когда поступили данные от ИСОУ «Виртуальная школа».
      Спецификация раздела «Журнал взаимодействия» должна иметь следующие поля:
      * «Тип сообщения» - текстовое поле, которое может принимать следующие значение: «Сообщение», «Ошибка»;
      * «Вид операции» - текстовое поле, значение соответствует полю «Вид операции» заголовка раздела;
      * «Учреждение» -  текстовое поле, для записи Id учреждения, по которому возникла ошибка на этапе обработки данных;
      * «Лицевой счет» - текстовое поле, для записи лицевого счета учащегося, по которому возникла ошибка на этапе обработки данных;
      * «Текст ошибки» - текстовое поле, для записи полного текста ошибки при обработке данных.
      * Раздел «Журнал взаимодействия» должен иметь следующие действия:
      * «Получить тип питание» - действие по которому выполняется обращение на сервис, для получения данных по типам питания;
      * «Отправить квитанции» - действие по которому формируется массив данных по квитанциям и отправляется на сервис;
      * «Отправка оплат» - действие по которому формируется массив данных по оплатам и отправляется на сервис;
      * «Синхронизировать» - действие, по которому идет обращение к сервису и выполняются пользовательские задания по загрузке данных;
      * «Отработать» - действие повторной отработки записей, по котором были ошибки в предыдущих загрузках.

       2.3 Проектирование интеграции информационных системам «Парус 8» и «ИСОУ «Виртуальная школа» с помощью веб-сервиса по средствам API
      
      2.3.1 Загрузка данных в раздел «Заказы питания»
      Параметры загрузки.
      Данные по заказам питания передаются в следующем формате, таблица 1.
      
Таблица 1 - Формат данных заказов питания
Параметр
Тип данных
Размерность
Наименование
schoolId
 Int 
 
Идентификатор школы
classId
Int
 
Идентификатор класса
checkingAccount
String 
 
Лицевой счет
dateTime
String
[dd.MM.yyyy HH:mm:ss]
Дата и время заказа
studentFullName
String
 
ФИО ученика
foodTypeId
Int 
 
Идентификатор типа питания
regionalBudget
Int 
 
Региональный бюджет
municipalBudget
Int
 
Муниципальный бюджет
parentalPayment
Int
 
Родительская оплата
      
      Данные загружаются из сервиса по API. Параметры API: PUT/provders/{providerId}/food_orders
      Тело запроса объектов в json описано в приложении 
      Данные должны загружаться в раздел «Заказы питания». 
      Алгоритм добавления данных: 
      a) В разделе «Заказы питания» осуществляем поиск по полю «Номер лицевого счета», значение поля «Номер лицевого счета» равно значению поля «checkingAccount».  Иначе, в п.d.
      b) Далее смотрим поле «dateTime», 
      Если значение поля меньше «текущая дата минус один»,  то  по записям найденных в п.1 обращаемся к спецификации «Заказы питания (Питание)» и удаляем записи, у которых значение поля «Дата» в спецификации равно значению поля «dateTime».
      Иначе, у найденной записи в п.1 смотрим поле «Признак активности»,
      Если «Признак активности» = Да, то переходим к спецификации «Заказы питания (Питание)» пункт c. 
      Иначе переходим к п.d.
      c) В спецификацию «Заказы питания (Питание)» добавляем записи, где 
      * в поле «Дата» записываем значение из поля «dateTime»;
      * в поле «Наименование блюда» записываем значение, у которого значение поля «foodTypeId» равно значению «Мнемокода» словаря «Заказы питания (Блюда)».
      * поля «Тип питания», «Региональный бюджет», «Муниципальный бюджет» и «Родительская оплата» заполняются соответственно из словаря «Заказы питания (Блюда)»  Спецификации «Периоды действия» в зависимости от заполнения поля «Наименование блюда».
      d) В заголовке раздела «Заказы питания» должна добавляться новая запись, в которой:
      В поле «Период» записываем период, который определяется по полю «dateTime», например «dateTime» = 05.09.2017, то период – Сентябрь, записываем в формате 09/2017.
      Личная карточка должна выбираться по лицевому счету. Значение поля «checkingAccount» равно значению поля «Номер лицевого счета» в разделе «Личные карточки».  
      Значение поля «Учреждение», «Класс» и «Признак активности» заполняются автоматически из спецификации «История» раздела «Личные карточки» по полю «Признак активности» = «Да».  
      Поля «Тип питания», «Региональный бюджет», «Муниципальный бюджет» и «Родительская оплата» заполняются соответственно из словаря «Заказы питания (Блюда)»  Спецификации «Периоды действия» в зависимости от заполнения поля «Наименование блюда».
      e) Далее должна заполняться спецификация «Заказы питания (Питание)». Алгоритм заполнения спецификации описан в пункте c.

      2.3.2 Загрузка данных по учащимся
      Параметры загрузки:
      Данные по учащимся передаются в следующем формате, таблица 2.
      
Таблица 2 - Формат данных по учащимся
Параметр
Тип данных
Размерность
Наименование
schoolId
 Int
 
ID школы
schoolName
 String
 
Наименование школы
classId
 Int
 
ID класса
className
String
 
Наименование класса
checkingAccount
String 
 
Лицевой счет
studentFullName
String
 
 ФИО ученика
recommendedPayment
 Int 
 
 Рекомендованный платеж
studentActive
Boolean 
 
 Признак активности ученика
enrollmentDate
 Date
[ddMMyyyy]
Дата зачисления
dismissalDate
Date
[ddMMyyyy]
Дата выбытия
      
      Данные загружаются из сервиса по API. Параметры API: PUT/provders/{providerId}/students
      Тело запроса объектов в json описано в приложении 
      Данные должны загружаться в раздел «Контрагенты» и «Личные корточки». Алгоритм добавления данных: 
      В разделе «Контрагенты»  осуществляем поиск в поле «Мнемокод» по значению «checkingAccount»
      если запись контрагента найдена, то обновляем поля: Фамилия («studentFullName»), Имя («studentFullName»), Отчество («studentFullName»), (Наименование studentFullName). 
      Далее определяем наличие личной карточки по checkingAccount
      если запись существует, то в спецификацию «История» добавляем запись, у которой:
      * «Дата обновления» - дата загрузки данных;
      * «Дата постановки на учет» - значение поля «enrollmentDate»;
      * «Дата снятия с учета» - значение поля «dismissalDate»
      * «Наименование школы» - определяем по полю «schoolId». Значение поля «schoolId» ищем в разделе «Учреждения» в поле «Мнемокод». Если запись найдена, то в поле «Наименование школы» записываем мнемокод контрагента найденной записи. Иначе, поле остается пустым.
      * «Наименование класса» - определяем по полю «classId». Значение поля «classId» ищем в спецификации «Группы» учреждения, выбранного в поле «Наименование школы». Если соответствия не найдено, то поле остается пустым.
      * «Признак активности» - значение соответствует полю «studentActive». Если значение поля «studentActive» = true, то «Признак активности» = Да, иначе «Признак активности» = Нет.
      Если личная карточка не определена, то добавляем (описание см.ниже).
      После этого переходим к следующей записи в загружаемом файле.
      если запись контрагента не найдена, то должна создаваться новая запись, в которой:
      * поле «Тип» - «Физическое лицо»;
      * поле «Фамилия» - значение 1 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);
      * поле «Имя» - значение 2 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);
      * поле «Отчество» - значение 3 подстроки поля «studentFullName» загружаемого файла, (разделитель пробел);
      * поле «Мнемокод» - значение поля «checkingAccount»;
      * поле «Наименование» - значение поля «studentFullName»
      * добавление личной карточки
      * после добавления контрагента переходим к добавлению личной карточки (В разделе «Личные карточки»):
      * поле «Номер» - текущий номер по порядку;
      * поле «Контрагент» - записываем контрагента добавленного в раздел «Контрагенты» (по значению «checkingAccount»);
      * поле «Номер лицевого счета» – в префикс записываем «ВШ», в номер записываем значение поля «checkingAccount» загружаемого файла;
      * поле «Дата постановки на учет» - значение поля «enrollmentDate»;
      Далее заполняем спецификацию «История»:
      добавляем запись, у которой:
      * «Дата обновления» - дата загрузки данных;
      * «Дата постановки на учет» - значение поля «enrollmentDate»;
      * «Дата снятия с учета» - значение поля «dismissalDate»
      * «Наименование школы» - определяем по полю «schoolId». Значение поля «schoolId» ищем в разделе «Учреждения» в поле «Мнемокод». Если запись, найдено, то в поле «Наименование школы» записываем мнемокод контрагента найденной записи. Иначе, поле остается пустым.
      * «Наименование класса» - определяем по полю «classId». Значение поля «classId» ищем в спецификации «Группы» учреждения выбранного в поле «Наименование школы». Если соответствия не найдено, то поле остается пустым.
      * «Признак активности» - значение соответствует полю «studentActive». Если значение поля «studentActive» = true, то «Признак активности» = Да, иначе «Признак активности» = Нет.
      
      2.3.3 Выгрузка квитанций по лицевым счетам
      Параметры выгрузки.
      Данные выгружаются с сервиса по API. Параметры API: PUT/food_providers/{providerId}/receipts
      Тело запроса объектов в json описано в приложении 
      Данные для выгрузки:
      * В поле «Получатель платежа» записываем значение из поля "Учреждение" раздела «Заказы питания»
      * В поле «ЛС» записываем значение, которое определяется по связи: «Учреждения»- «Контрагенты» - «Реквизиты лицевых счетов в финансовых учреждениях». (Определяем поле «Номер счета». В спецификации «Реквизиты лицевых счетов в финансовых учреждениях» ищем строку у которой поле «Код строки»= «*ицевой*», в найденной строке считываем значение «Номер счета» и записываем его в поле «ЛС» ).
      * В поле «ИНН» записываем значение из поля «Идентификационный номер налогоплательщика» заголовка раздела «Контрагенты» по значению указанного в поле «Получатель платежа».
      * В поле «OKTMO» записываем значение из поля «Код ОКТМО» заголовка раздела «Контрагенты» » по значению указанного в поле «Получатель платежа».
      * Описание заполнения полей "Счет", "Банк", "БИК".
      * Значение полей "ЛС", "Счет", "Банк" и "БИК" брать из строки, указанной в поле "Банковские реквизиты контрагента" в разделе "Учреждения".
      * Если в поле "Банковские реквизиты контрагента" указано значение, у которого заполнено поле "Казначейство", то по связи: «Казначейство»-«Реквизиты казначейства в банке». В поле «Счет» записываем значение из поля «Счет», в поле «Банк» записываем значение из поля «Наименование», в поле «БИК» записываем значение из поля «Код банка (БИК)». 
      * Если в поле "Банковские реквизиты контрагента" указано значение, у которого заполнено поле "Казначейство", то в поле «ЛС» записываем значение из поля «Номер счета» по связи: «Контрагент»-«Реквизиты лицевых счетов в банковских учреждениях» - поле «Номер счета» (вкладка Реквизиты).
      * Иначе, л/с организации выбираем из поля "Лицевой счет" заголовка раздела "Учреждения". Значение полей "Счет", ".......................