• Посилання скопійовано
Документ підготовлено в системі iplex

Про затвердження Порядку доступу до інформації центральної бази даних програмноапаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту"

Міністерство освіти і науки України | Наказ, Вимоги, Порядок від 05.09.2022 № 792
Реквізити
  • Видавник: Міністерство освіти і науки України
  • Тип: Наказ, Вимоги, Порядок
  • Дата: 05.09.2022
  • Номер: 792
  • Статус: Документ діє
  • Посилання скопійовано
Реквізити
  • Видавник: Міністерство освіти і науки України
  • Тип: Наказ, Вимоги, Порядок
  • Дата: 05.09.2022
  • Номер: 792
  • Статус: Документ діє
Документ підготовлено в системі iplex
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАКАЗ
05.09.2022 № 792
Зареєстровано в Міністерстві
юстиції України
11 жовтня 2022 р.
за № 1218/38554
Про затвердження Порядку доступу до інформації центральної бази даних програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту"
Відповідно до абзацу третього пункту 12 Положення про програмно-апаратний комплекс "Автоматизований інформаційний комплекс освітнього менеджменту", затвердженого постановою Кабінету Міністрів України від 02 грудня 2021 року № 1255, пункту 8 Положення про Міністерство освіти і науки України, затвердженого постановою Кабінету Міністрів України від 16 жовтня 2014 року № 630, із метою вдосконалення та автоматизації процесів управління закладом освіти НАКАЗУЮ:
1. Затвердити Порядок доступу до інформації центральної бази даних програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту", що додається.
2. Директорату цифрової трансформації (Завгородній Д.) забезпечити в установленому порядку подання цього наказу на державну реєстрацію до Міністерства юстиції України.
3. Цей наказ набирає чинності з дня його офіційного опублікування.
4. Контроль за виконанням цього наказу залишаю за собою.

Міністр

С. Шкарлет

ПОГОДЖЕНО:

Уповноважений Верховної Ради України
з прав людини

Голова Державної регуляторної служби України

Перший заступник Міністра
цифрової трансформації України




Д. Лубінець

О. Кучер


О. Вискуб
ЗАТВЕРДЖЕНО
Наказ Міністерства освіти
і науки України
від 05 вересня 2022 року № 792
Зареєстровано в Міністерстві
юстиції України
11 жовтня 2022 р.
за № 1218/38554
ПОРЯДОК
доступу до інформації центральної бази даних програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту"
1. Цей Порядок визначає процедуру надання технічним адміністратором програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту" (далі - АІКОМ) доступу до інформації центральної бази даних АІКОМ користувачам системи та стороннім електронним освітнім інформаційним системам, що забезпечують автоматизацію освітніх і управлінських процесів закладів освіти.
2. Для цілей цього Порядку терміни використовуються в такому значенні:
користувач системи - учасники освітнього процесу, суб’єкти освітньої діяльності, засновники закладів освіти, органи управління освітою та установи, визначені МОН, що належать до сфери його управління, який має в АІКОМ обліковий запис;
технічний адміністратор АІКОМ (далі - Адміністратор) - державна наукова установа "Інститут освітньої аналітики", що належить до сфери управління МОН.
Інші терміни вживаються в значеннях, наведених у Законах України "Про освіту", "Про повну загальну середню освіту", Положення про програмно-апаратний комплекс "Автоматизований інформаційний комплекс освітнього менеджменту", затвердженого постановою Кабінету Міністрів України від 02 грудня 2021 року № 1255, та іншого законодавства.
3. Доступ до інформації центральної бази даних АІКОМ забезпечується користувачам системи шляхом створення їхніх облікових записів для взаємодії з центральною базою даних АІКОМ в частині обміну даними щодо освітніх та/або управлінських процесів.
Процедура створення облікових записів користувачів системи визначається Адміністратором.
Доступ до інформації центральної бази даних АІКОМ надається користувачу системи в межах, що визначаються сферою його діяльності.
4. Для безпечного входу в обліковий запис користувача системи Адміністратор створює електронний ключ доступу до облікового запису в центральній базі даних АІКОМ (далі - базовий ключ доступу) та передає його користувачу системи шляхом надсилання на його офіційну електронну пошту. Окремий ключ доступу до облікового запису користувача системи з набором прав для спеціального протоколу обміну інформацією (далі - ключ АРІ) автоматично генерується системою при створенні базового ключа доступу.
5. Користувачі системи для організації електронного діловодства та/або автоматизації управлінських процесів можуть використовувати сторонню електронну освітню інформаційну систему (далі - ОІС), яка підключена до центральної бази даних АІКОМ. Для цього користувач системи передає ОІС ключ АРІ для реалізації взаємодії на підставі договору про використання зазначеної системи, який укладається з урахуванням документів, зазначених у пункті 6 цього Порядку.
Перелік ОІС, що підключені до центральної бази даних АІКОМ, опубліковується на офіційному вебсайті Адміністратора.
6. Підключення ОІС до центральної бази даних АІКОМ здійснюється Адміністратором на підставі договору про приєднання до центральної бази даних програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту", який укладається відповідно до примірного договору про приєднання до центральної бази даних програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту" затвердженого Міністерством освіти і науки України, і з урахуванням висновку Адміністратора про відповідність ОІС Технічним вимогам до електронної освітньої інформаційної системи для підключення до центральної бази програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту" згідно з додатком.
7. Зупинення доступу користувача системи до інформації центральної бази даних АІКОМ забезпечується шляхом деактивації облікових записів.
8. Зупинення доступу ОІС до облікового запису користувача системи здійснюється шляхом деактивації ключа АРІ Адміністратором за запитом користувача системи та генерацією нового.
9. Технічна підтримка щодо надання доступу до інформації центральної бази даних АІКОМ забезпечується Адміністратором.
10. Деактивація облікових записів користувачів системи здійснюється в разі:
ліквідації, реорганізації користувача системи;
несанкціонованого втручання в роботу АІКОМ;
виявлення кіберзагроз, кіберінцидентів і кібератак, а також ризиків настання таких подій.
11. Деактивовані облікові записи закладів освіти не підлягають подальшому використанню.
12. Забезпечення захисту інформації центральної бази даних АІКОМ здійснюється відповідно до Закону України "Про захист інформації в інформаційно-комунікаційних системах".

Т.в.о. Генерального директора
директорату цифрової
трансформації



А. Василенко
Додаток
до Порядку доступу до інформації
центральної бази даних
програмно-апаратного комплексу
"Автоматизований інформаційний
комплекс освітнього менеджменту"
(пункт 6)
ТЕХНІЧНІ ВИМОГИ
до електронної освітньої інформаційної системи для підключення до центральної бази програмно-апаратного комплексу "Автоматизований інформаційний комплекс освітнього менеджменту"
ЗМІСТ
Зв’язки бази даних
1. Загальні вимоги до електронної освітньої інформаційної системи
2. Загальні вимоги до безпеки
3. Функціональні вимоги до модулів ОІС
3.1. Заклад освіти
3.2. Вимоги до сутності семестр "Semester"
3.2.1. Загальні дані сутності семестр "Semester"
3.2.2. Вимоги до полів сутності семестр "Semester"
3.2.3. Обов’язкові поля сутності семестр "Semester"
3.2.4. Вимоги до дій із сутністю семестр "Semester"
3.3. Вимоги до сутності клас "Class"
3.3.1. Загальні дані сутності клас "Class"
3.3.2. Вимоги до полів сутності клас "Class"
3.3.3. Обов’язкові поля сутності клас "Class"
3.3.4. Вимоги до дій із класом "Class"
3.4. Вимоги до сутності учень "Student"
3.4.1. Загальні дані сутності учень "Student"
3.4.2. Вимоги до полів сутності учень "Student"
3.4.3. Обов’язкові поля сутності учень "Student"
3.4.4. Вимоги до дій з учнем "Student"
3.5. Вимоги до сутності предмет "Subject"
3.5.1. Загальні дані сутності предмет "Subject"
3.5.2. Вимоги до полів сутності предмет "Subject"
3.5.3. Обов’язкові поля сутності предмет "Subject"
3.5.4. Вимоги до дій із предметом "Subject"
3.6. Вимоги до сутності зміна "Shift"
3.6.1. Загальні дані сутності зміна "Shift"
3.6.2. Вимоги до полів сутності зміна "Shift"
3.6.3. Обов’язкові поля сутності зміна "Shift"
3.6.4. Вимоги до дій зі зміною "Shift"
3.7. Вимоги до сутності дзвінки "Calls"
3.7.1. Загальні дані сутності дзвінки "Calls"
3.7.2. Вимоги до полів сутності дзвінки "Calls"
3.7.3. Обов’язкові поля сутності дзвінки "Calls"
3.7.4. Вимоги до дій із дзвінками "Calls"
3.8. Вимоги до сутності приміщення "Room"
3.8.1. Загальні дані сутності приміщення "Room"
3.8.2. Вимоги до полів сутності приміщення "Room"
3.8.3. Обов’язкові поля сутності приміщення "Room"
3.8.4. Вимоги до дій із приміщенням "Room"
3.9. Вимоги до сутності журнал "Journal"
3.9.1. Загальні дані сутності журнал "Journal"
3.9.1.1. Вимоги до полів сутності журнал "Journal"
3.9.1.2. Обов’язкові поля сутності журнал "Journal" (без підгруп)
3.9.1.3. Обов’язкові поля сутності журнал "Journal" (з підгрупами)
3.9.1.4. Вимоги до дій із журналом "Journal"
3.10. Вимоги до сутності підгрупи в журналах "Subgroup"
3.10.1. Загальні дані сутності підгрупи в журналах "Subgroup"
3.10.2. Вимоги до полів сутності підгрупи в журналах "Subgroup"
3.10.3. Вимоги до дій із підгрупами в журналах "Subgroup"
3.11. Вимоги до сутності уроки закладу освіти "Lesson"
3.11.1. Загальні дані сутності уроки закладу освіти "Lesson"
3.11.2. Вимоги до полів сутності уроки закладу освіти "Lesson"
3.11.3. Обов’язкові поля сутності уроки закладу освіти "Lesson"
3.11.4. Вимоги до дій з уроками закладу освіти "Lesson"
3.12. Вимоги до сутності уроки закладу освіти "Mark"
3.12.1. Загальні дані сутності уроки закладу освіти "Mark"
3.12.2. Вимоги до полів сутності уроки закладу освіти "Mark"
3.12.3. Обов’язкові поля сутності уроки закладу освіти "Mark"
3.12.4. Вимоги до дій із уроками закладу освіти "Mark"
3.13. Вимоги до сутності персонал "Personnel"
3.13.1. Загальні дані сутності персонал "Personnel"
3.13.2. Вимоги до полів сутності персонал "Personnel"
3.13.3. Обов’язкові поля сутності персонал "Personnel"
3.13.4. Вимоги до дій із персоналом "Personnel"
Зв’язки бази даних
1. Загальні вимоги до електронної освітньої інформаційної системи
1.1. Електронна освітня інформаційна система (далі - ОІС) забезпечує можливість обміну даними з центральною базою освіти (далі - Система) через відкритий прикладний програмний інтерфейс (далі - АРІ).
1.2. ОІС забезпечує можливість внесення інформації до центральної бази даних (далі - ЦБД) Системи через свій інтерфейс українською мовою. У випадках, коли використання літер українського алфавіту призводить до спотворення інформації, можуть використовуватися латинські літери та спеціальні символи, зокрема для запису адрес у інтернеті й адрес електронної пошти.
1.3. ОІС повинна мати сертифікат відповідності Комплексної системи захисту інформації та мати логін та пароль, які надають доступ до сутностей проекту.
1.4. ОІС повинна надавати функціональну можливість засвідчення даних, що вносяться до ЦБД користувачами за допомогою кваліфікованого електронного підпису (далі - КЕП).
1.5. У разі, якщо процес засвідчення КЕП відбувається за межами ОІС, остання має забезпечувати перевірку незмінності даних у підписному контенті.
1.6. ОІС надає доступ до Системи через свій інтерфейс після введення логіна та пароля користувача.
1.7. Авторизація проходить за полями: "username" і "password".
1.8. Для забезпечення доступу користувача до ЦБД Системи ОІС повинна використовувати "access token" згідно зі специфікацією API Системи, контролювати дані про дату валідності "access token" (параметр "expiry date") і в разі закінчення дії оновлювати його.
1.9. У запитах на гарантування обсягу аутентифікації ("scopes") користувачів ОIC передає не більший, ніж визначений специфікацією Системи, список прав, які необхідні користувачу для подальшої роботи з ЦБД Системи.
1.10. ОІС повинна правильно відобразити текст і прапорець ("checkbox") для елемента "Consent" (погодження з правилами), а також продемонструвати або дати можливість перевірити, що елемент погодження з правилами відображається вірно та що користувач може надати згоду з відповідними правилами після ознайомлення з ними.
1.11. У разі виникнення помилок у Системі (неправильне введення даних користувачами, хибна авторизація тощо) ОІС відображає помилки її кінцевим користувачам у текстовому вигляді.
1.12. При роботі із Системою для користувача повинна бути забезпечена можливість отримання актуальних словників, класифікаторів від ЦБД відповідним запитом ОІС та інформації з відповідних вебсторінок. У випадку реалізації кешування ОІС повинна забезпечити синхронізацію довідників, класифікаторів і вебсторінок щонайменше 1 раз на добу.
1.13. ОІС відображає користувачу назви полів у інтерфейсах згідно з вимогами, що розробляються та затверджуються Адміністратором.
1.14. На підставі виконання користувачем визначених дій та/або значень параметрів Системи ОІС забезпечує інформування користувача через повідомлення в інтерфейсі. Підстава інформування й текст повідомлення розробляються та затверджуються Адміністратором (наприклад, інформування про регламентні роботи);
1.15. У разі створення ідентифікатора запису на стороні ОІС для використання його в методах АРІ Системи ОІС потрібно передавати тільки оновлення - з моменту останньої передачі даних.
1.16. Коректність даних забезпечує сторона, що їх передає.
1.17. Якщо ОІС при передачі даних отримано помилку, то ОІС потрібно повторити відправку даних у наступній ітерації.
2. Загальні вимоги до безпеки
2.1. ОІС має забезпечувати розмежування доступу до даних, внесених до ЦБД Системи.
2.2. ОІС повинна використовувати тільки безпечні способи передачі даних, а саме:
2.2.1. між ОІС і ЦБД - протокол "Transport Layer Security" (далі - TLS) версії не нижче 1.2, що відповідає вимогам чинного законодавства;
2.2.2. між ОІС та користувачем ОІС - протокол TLS версії не нижче 1.2 або інший спосіб, що відповідає вимогам чинного законодавства.
2.3. ОІС заборонено зберігати паролі КЕП та файли приватних ключів.
2.4. ОІС повинна відповідати вимогам законів України "Про захист інформації в інформаційно-комунікаційних системах", "Про захист персональних даних" і інших нормативно-правових актів, що регулюють питання захисту інформації, у тому числі в інформаційно-комунікаційних системах.
3. Функціональні вимоги до модулів ОІС
3.1. Заклад освіти
3.1.1. ОІС отримує в Адміністратора системи логін і пароль АРІ.
3.1.2. ОІС, для того щоб заклад освіти, згідно з його типом і особливостями, міг передавати свої дані в систему, повинна закріпити логін і пароль АРІ за відповідним закладом освіти.
3.1.3. У разі відсутності логіна й пароля АРІ для закладу освіти, ОІС необхідно звернутися до Адміністратора.
3.1.4. Якщо логін і пароль АРІ введено правильно, то система дозволяє ОІС робити оновлення в базі, зміни в даних у відповідних полях щодо конкретного закладу освіти.
3.1.5. Якщо логін і пароль АРІ введено неправильно, то у відповідь від системи ОІС отримає повідомлення про помилку взаємодії з базою в рамках конкретного закладу освіти.
3.1.6. Якщо до ОІС хоче приєднатися новий заклад освіти, тоді, перед початком взаємодії, ОІС треба звернутися до Адміністратора щодо отримання нових логіна та пароля АРІ.
3.2. Вимоги до сутності семестр "Semester"
3.2.1. Загальні дані сутності семестр "Semester"
3.2.1.1. ОІС зберігає поля "start_date" (дата початку окремого семестру) та "end_date" (дата закінчення окремого семестру) у форматі дати "(dd.mm.yyyy)".
3.2.1.2. ОІС повинна перевіряти, щоб при створенні й використанні дата початку нового семестру не накладалася на дату закінчення попереднього семестру.
3.2.1.3. ОІС має передавати до системи ID (унікальний номер запису) актуального семестру.
3.2.2. Вимоги до полів сутності семестр "Semester"
3.2.2.1. Вимоги до назви поля "унікальний номер семестру" поле - "semester_id".
3.2.2.2. Вимоги до назви поля "назва семестру" - "name".
3.2.2.3. Вимоги до назви поля "дата початку семестру" - "start_date".
3.2.2.4. Вимоги до назви поля "дата закiнчення семестру" - "end_date".
3.2.3. Обов’язкові поля сутності семестр "Semester"
3.2.3.1. ОІС повинна обов’язково передавати до системи поле "назва семестру" - "name".
3.2.3.2. ОІС повинна обов’язково передавати до системи поле "дата початку семестру" - "start_date".
3.2.3.3. ОІС повинна обов’язково передавати до системи поле "дата закінчення семестру" - "end_date".
3.2.4. Вимоги до дій із сутністю семестр "Semester"
3.2.4.1. Для створення нового запису семестру використовується дія - "create" (/semester/create).
3.2.4.2. Для перегляду даних про семестр використовується дія - "view" (/semester/view?id=945417), де id - унікальний номер запису семестру в системі, інформація про який переглядається.
3.2.4.3. Для перегляду даних про всі семестри використовується дія - "index" (/semester/index).
3.2.4.4. Для перегляду списку всіх семестрів використовується дія - "semester-list" (/semester/semester-list).
3.2.4.5. Для перегляду інформації про поточний семестр використовується дія - "get-current" (/semester/get-current).
3.2.4.6. Для встановлення семестру з обраним ID як поточного семестру використовується дія - "set-current" (/semester/set-current).
3.2.4.7. Для редагування даних про семестр використовується дія - "update" (/semester/update?id=945424), де id - унікальний номер запису семестру, який редагується.
3.2.4.8. Для видалення запису використовується дія - "delete" (/semester/delete?id=945423), де id - унікальний номер запису семестру, який видаляється.
3.3. Вимоги до сутності клас "Class"
3.3.1. Загальні дані сутності клас "Class"
3.3.1.1. ОІС повинна зберігати поле "name" у форматі: максимум 2 цифри та 3 літери українською мовою. Запис до бази даних щодо поля понад установлені межі має блокуватися ОІС на етапі вводу або збереження.
3.3.1.2. ОІС повинна перевіряти відсутність дублювання класів (щоб не було два чи більше класів із однаковими полями "name") у одному семестрі. Бажано на етапі створення/збереження класу.
3.3.1.3. ОІС має перевіряти обов’язковість полів.
3.3.2. Вимоги до полів сутності клас "Class"
3.3.2.1. Вимоги до назви поля "унікальний номер класу" - "class_id".
3.3.2.2. Вимоги до назви поля ID представника персоналу закладу, який є класним керівником класу - "personal_id".
3.3.2.3. Вимоги до назви поля ID семестру - "semester_id".
3.3.2.4. Вимоги до назви поля ID зміни - "smena_id".
3.3.2.5. Вимоги до назви поля "назва класу" - "name".
3.3.3. Обов’язкові поля сутності клас "Class"
3.3.3.1. ID представника персоналу закладу, який є класним керівником класу - "personal_id".
3.3.3.2. ID зміни - "smena_id".
3.3.3.3. ID семестру - "semester_id".
3.3.3.4. Назва класу - "name".
3.3.4. Вимоги до дій із класом "Class"
3.3.4.1. Для перегляду даних про всі класи використовується дія - "index" (/class/index).
3.3.4.2. Для перегляду списку всіх класів використовується дія - "class-list" (/class/class-list).
3.3.4.3. Для створення нового запису класу використовується дія - "create" (/class/create).
3.3.4.4. Для редагування даних про клас використовується дія - "update" (/class/update?id= 39605891), де id - унікальний номер запису класу, який редагується.
3.3.4.5. Для перегляду даних про семестр використовується дія - "view" (/class/view?id= 8835891), де id - унікальний номер запису класу, інформація про який переглядається.
3.3.4.6. Для видалення запису використовується дія - "delete" (/class/delete?id=8835898), де id - унікальний номер запису класу, який видаляється.
3.4. Вимоги до сутності учень "Student"
3.4.1. Загальні дані сутності учень "Student"
3.4.1.1. ОІС повинна перевіряти "student_birth", щоб дата була актуальною.
3.4.1.2. ОІС має перевіряти наявність заповнення всіх обов’язкових полів.
3.4.1.3. ОІС повинна перевіряти за ідентифікаційним кодом учня (згідно з нормами формування коду) його стать.
3.4.1.4. ОІС має перевіряти за ідентифікаційним кодом учня (згідно з нормами формування коду) його дату народження.
3.4.1.5. ОІС зберігає поля "personal_birth" у форматі дати "(dd.mm.yyyy)".
3.4.1.6. ОІС зберігає поля "student_sex" у форматі "(чоловіча "1", жіноча "0")".
3.4.1.7. ОІС зберігає "вибув" - "c_leave" у форматі ("1" - вибув, "0" - навчається)").
3.4.1.8. ОІС повинна перевіряти, щоб поля "firstname", "lastname", "patronymic" були написані українською мовою (максимальна кількість символів 36 символів). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження.
3.4.2. Вимоги до полів сутності учень "Student"
3.4.2.1. Вимоги до назви поля "унікальний номер учня" - "student_id".
3.4.2.2. Вимоги до назви поля "унікальний номер класу" - "class_id".
3.4.2.3. Вимоги до назви поля "ім’я учня" - "firstname".
3.4.2.4. Вимоги до назви поля "прізвище учня" - "lastname".
3.4.2.5. Вимоги до назви поля "по батькові учня" - "patronymic".
3.4.2.6. Вимоги до назви поля "дата народження учня" - "student_birth".
3.4.2.7. Вимоги до назви поля "стать учня" - "student_sex".
3.4.3. Обов’язкові поля сутності учень "Student"
3.4.3.1. Поле "унікальний номер класу" - "class_id".
3.4.3.2. Поле "ім’я учня" - "firstname".
3.4.3.3. Поле "прізвище учня" - "lastname".
3.4.3.4. Поле "ідентифікаційний код учня" - "student_inn".
3.4.3.5. Поле "стать учня" - "student_sex".
3.4.3.6. Поле "вибув" - "c_leave".
3.4.4. Вимоги до дій з учнем "Student"
3.4.4.1. Для створення нового запису учня використовується дія - "create" (/student/create).
3.4.4.2. Для перегляду даних про окремого учня використовується дія - "view" (/student/view?id=39605877), де id - унікальний номер запису учня, інформація про якого переглядається.
3.4.4.3. Для редагування даних про окремого учня використовується дія - "update" (/student/update?id=39605891), де id - унікальний номер запису учня, який редагується.
3.4.4.4. Для видалення запису про окремого учня використовується дія - "delete" (/student/delete?id=39605890), де id - унікальний номер запису учня, який видаляється.
3.5. Вимоги до сутності предмет "Subject"
3.5.1. Загальні дані сутності предмет "Subject"
3.5.1.1. ОІС повинна перевіряти поле "name" на кількість символів (максимум 128 символів). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження.
3.5.1.2. ОІС повинна перевіряти поле "shortname" на кількість символів (максимум 10 символів). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження.
3.5.1.3. ОІС повинна перевіряти поле "name" предмета на дублювання та не дозволяти створювати однакові поля. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватися ОІС на етапі вводу або збереження.
3.5.1.4. ОІС перевіряє поле "у використанні" - "in_use". Формат поля ("0"- не використовується, "1" - використовується")
3.5.1.5. ОІС повинна перевіряти наявність заповнення в записі предмета всіх обов’язкових полів.
3.5.2. Вимоги до полів сутності предмет "Subject"
3.5.2.1. Вимоги до назви поля "унікальний номер предмета" - "predmet_id".
3.5.2.2. Вимоги до назви поля "ID семестру" - "semester_id".
3.5.2.3. Вимоги до назви поля "повна назва предмета" - "name".
3.5.2.4. Вимоги до назви поля "скорочена назва предмета" - "shortname".
3.5.2.5. Вимоги до назви поля "у використанні" - "in_use".
3.5.3. Обов’язкові поля сутності предмет "Subject"
3.5.3.1. Поле "повна назва предмета" - "name".
3.5.3.2. Поле "скорочена назва предмета" - "shortname".
3.5.3.3. Поле "у використанні" - "in_use".
3.5.4. Вимоги до дій із предметом "Subject"
3.5.4.1. Для перегляду даних про всі предмети використовується дія - "index" (/subject/index).
3.5.4.2. Для перегляду списку всіх предметів використовується дія - "subject-list" (/subject/subject-list).
3.5.4.3. Для створення нового запису предмета використовується дія - "create" (/subject/create).
3.5.4.4. Для редагування даних про предмет використовується дія - "update" (/subject/update?id=30631741), де id - унікальний номер запису предмета, який редагується.
3.5.4.5. Для перегляду даних про предмет використовується дія - "view" (/subject/view?id= 30631741), де id - унікальний номер запису предмета, інформація про який переглядається.
3.5.4.6. Для видалення запису предмета використовується дія - "delete" (/subject/delete?id= 30631740), де id - унікальний номер запису предмета, який видаляється.
3.6. Вимоги до сутності зміна "Shift"
3.6.1. Загальні дані сутності зміна "Shift"
3.6.1.1. ОІС повинна перевіряти поле "name" на кількість символів (максимум 30 символів). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.6.1.2. ОІС повинна перевіряти поле "name" на дублювання та не дозволяти створювати однакові поля. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.6.1.3. ОІС перевіряє поле "опис" - "description" на кількість символів (максимум 100 символів).
3.6.1.4. ОІС повинна перевіряти всі обов’язкові поля.
3.6.1.5. ОІС повинна перевіряти формат поля "lesson_max_time" (00:00:00). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.6.2. Вимоги до полів сутності зміна "Shift"
3.6.2.1. Вимоги до назви поля "унікальний номер зміни" - "smena_id".
3.6.2.2. Вимоги до назви поля "ID семестру" - "semester_id".
3.6.2.3. Вимоги до назви поля "назва зміни" - "name".
3.6.2.4. Вимоги до назви поля "опис" - "description".
3.6.2.5. Вимоги до назви поля "максимальний час уроку" - "lesson_max_time".
3.6.3. Обов’язкові поля сутності зміна "Shift"
3.6.3.1. Поле "назва зміни" - "name".
3.6.3.2. Поле "опис" - "description".
3.6.3.3. Поле "максимальний час уроку" - "lesson_max_time".
3.6.4. Вимоги до дій зі зміною "Shift"
3.6.4.1. Для створення нового запису зміни використовується дія - "create" (/shift/create).
3.6.4.2. Для редагування даних про окрему зміну використовується дія - "update" (/shift/update?id=1193088), де id - унікальний номер запису зміни, яка редагується.
3.6.4.3. Для перегляду списку всіх змін використовується дія - "shift-list" (/shift/shift-list).
3.6.4.4. Для перегляду даних про окрему зміну використовується дія - "view" (/shift/view?id=1193088), де id - унікальний номер запису зміни, інформація про яку переглядається.
3.6.4.5. Для видалення запису окремої зміни використовується дія - "delete" (/shift/delete?id=30631740), де id - унікальний номер запису зміни, яка видаляється.
3.7. Вимоги до сутності дзвінки "Calls"
3.7.1. Загальні дані сутності дзвінки "Calls"
3.7.1.1. ОІС повинна перевіряти поле "time_start" та поле "time_stop", які відповідають початку й закінченню уроку. Початок і кінець уроку не повинні перетинатися. Поле "time_stop" завжди повинно бути більше ніж поле "time_start". Рекомендується перевіряти поле "time_stop" уже на етапі вводу, на основі заповненого поля "time_start". Формат поля "hh:mm"
3.7.1.2. ОІС повинна перевіряти поле "time_start" і поле "time_stop" на дублювання та не дозволяти різні окремі дзвінки в той самий час.
3.7.1.3. ОІС повинна перевіряти всі обов’язкові поля. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.7.1.4. ОІС повинна перевіряти формат поля "lesson_max_time" (00:00:00). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.7.1.5. Поле "name" повинне бути цілим числом. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.7.2. Вимоги до полів сутності дзвінки "Calls"
3.7.2.1. Вимоги до назви поля "унікальний номер дзвінків уроку" - "buzzer_id".
3.7.2.2. Вимоги до назви поля "ID зміни" - "smena_id".
3.7.2.3. Вимоги до назви поля "назва уроку в розкладі дзвінків" - "name".
3.7.2.4. Вимоги до назви поля "час початку уроку" - "time_start".
3.7.2.5. Вимоги до назви поля "час закінчення уроку" - "time_stop".
3.7.3. Обов’язкові поля сутності дзвінки "Calls"
3.7.3.1. Поле "ID зміни" - "smena_id".
3.7.3.2. Поле "назва уроку в розкладі дзвінків" - "name".
3.7.3.3. Поле "час початку уроку" - "time_start".
3.7.3.4. Поле "час закінчення уроку" - "time_stop".
3.7.4. Вимоги до дій із дзвінками "Calls"
3.7.4.1. Для створення нового запису використовується дія - "create" (/calls/create).
3.7.4.2. Для редагування даних про окремий дзвінок використовується дія - "update" (/calls/update?id=7877006), де id - унікальний номер запису дзвінків, які редагуються.
3.7.4.3. Для перегляду даних про всі дзвінки в розкладі дзвінків використовується дія - "index" (/calls/index).
3.7.4.4. Для перегляду списку всіх дзвінків використовується дія - "call–list" (/calls/call–list).
3.7.4.5. Для перегляду даних про окремий дзвінок уроку використовується дія - "view" (/calls/view?id=1193088), де id - унікальний номер запису дзвінків, інформація про які переглядається.
3.7.4.6. Для видалення запису про окремий дзвінок уроку використовується дія - "delete" (/calls/delete?id=30631740), де id - унікальний номер запису дзвінка, який видаляється.
3.8. Вимоги до сутності приміщення "Room"
3.8.1. Загальні дані сутності приміщення "Room"
3.8.1.1. Поле "area" повинне бути числом. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису. (Максимум 6 символів).
3.8.1.2. ОІС повинна перевіряти поле "name" на дублювання та не дозволяти створювати однакові поля. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису. (Максимум 48 символів).
3.8.1.3. ОІС перевіряє поле "не для навчання" - "is_not_for_studies". Формат поля "1- (так) не для навчання, 0 –(ні) для навчання"
3.8.1.4. ОІС повинна перевіряти всі обов’язкові поля.
3.8.1.5. ОІС повинна перевіряти формат поля "name" (максимум 60 символів) і номер (5 символів). Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі вводу або збереження запису.
3.8.1.6. Поле "name" може складатися з двох полів для ввода, але в БД зберігається в полі "name" (приклад: Історія [21]).
3.8.2. Вимоги до полів сутності приміщення "Room"
3.8.2.1. Вимоги до назви поля "унікальний номер кабінету" - "room_id".
3.8.2.2. Вимоги до назви поля "назва кабінету" - "name".
3.8.2.3. Вимоги до назви поля "площа кабінету" - "area".
3.8.2.4. Вимоги до назви поля "не для навчання" - "is_not_for_studies".
3.8.2.5. Вимоги до назви поля "ID семестру" - "semester_id".
3.8.3. Обов’язкові поля сутності приміщення "Room"
3.8.3.1. Поле "назва кабінету" - "name".
3.8.4. Вимоги до дій із приміщенням "Room"
3.8.4.1. Для створення нового запису приміщення використовується дія - "create" (/room/create).
3.8.4.2. Для редагування даних про окреме приміщення використовується дія - "update" (/room/update?id=19154371), де id - унікальний номер запису приміщення, яке редагується.
3.8.4.3. Для перегляду даних про всі приміщення в розкладі дзвінків використовується дія - "index" (/room/index).
3.8.4.4. Для перегляду списку всіх приміщень використовується дія - "room–list" (/room/call–list).
3.8.4.5. Для перегляду даних про окреме приміщення використовується дія - "view" (/room/view?id=1193088), де id - унікальний номер запису приміщення, інформація про яке переглядається.
3.8.4.6. Для видалення запису окремого приміщення використовується дія - "delete" (/room/delete?id=30631740), де id - унікальний номер запису приміщення, яке видаляється.
3.9. Вимоги до сутності журнал "Journal"
3.9.1. Загальні дані сутності журнал "Journal"
3.9.1.1. ОІС повинна перевіряти всі обов’язкові поля. Запис до бази даних полів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення.
3.9.1.2. ОІС повинна перевіряти наявність журналу з уже існуючим "class_id", "predmet_id", "personal_id" та не дозволяти його створити. Внесення до бази записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.9.1.3. ОІС повинна блокувати створення запису журналу, якщо в класі, для якого він створюється, немає учнів. При спробі створення або збереження такого запису рекомендується виводити для користувачів роз’яснювальне повідомлення.
3.9.1.4. ОІС перевіряє поля "опис підгрупи" - "subgroup", "назва підгрупи" - "name", "назва підгрупи" - "students". Поле має текстовий формат макимум 50 символів.
3.9.2. Вимоги до полів сутності журнал "Journal"
3.9.2.1. Вимоги до назви поля "унікальний номер журналу" - "id".
3.9.2.2. Вимоги до назви поля "ID семестру" - "semester_id".
3.9.2.3. Вимоги до назви поля "ID класу" - "class_id".
3.9.2.4. Вимоги до назви поля "ID предмета" - "predmet_id".
3.9.2.5. Вимоги до назви поля "ID підгрупи" - "subgroup_id".
3.9.2.6. Вимоги до назви поля "ID викладача" - "personal_id".
3.9.2.7. Вимоги до назви поля "ID помічника викладача" - "second_personal_id".
3.9.2.8. Вимоги до назви поля "ID дата останнього використання" - "last_used".
3.9.3. Обов’язкові поля сутності журнал "Journal" (без підгруп)
3.9.3.1. Поле "ID класу" - "class_id".
3.9.3.2. Поле "ID предмета" - "predmet_id".
3.9.3.3. Поле "ID підгрупи" - "subgroup_id", повинно бути "null".
3.9.3.4. Поле "ID викладача" - "personal_id".
3.9.3.5. Обов’язкові поля сутності журнал "Journal" (з підгрупами)
3.9.3.5.1. Поле "ID класу" - "class_id".
3.9.3.5.2. Поле "ID предмета" - "predmet_id".
3.9.3.5.3. Поле "ID викладача" - "personal_id".
3.9.3.5.4. Поле "опис підгрупи" - "subgroup".
3.9.3.5.5. Поле "назва підгрупи" - "name".
3.9.3.5.6. Поле "ID учнів у підгрупі" - "students".
3.9.4. Вимоги до дій із журналом "Journal"
3.9.4.1. Для створення нового запису для журналу без підгруп та журналу з підгрупами використовується дія - "create" (/journal/create).
3.9.4.2. Для редагування даних про окремий журнал використовується дія - "update" (/journal/update?id=3698), де id - унікальний номер запису журналу, який редагується.
3.9.4.3. Для перегляду даних про всі журнали використовується дія - "index" (/journal/index).
3.10. Вимоги до сутності підгрупи в журналах "Subgroup"
3.10.1. Загальні дані сутності підгрупи в журналах "Subgroup"
3.10.1.1. ОІС повинна перевіряти поле "name" у записі підгрупи на дублювання та не дозволяти створювати однакові записи. Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.10.1.2. ОІС повинна перевіряти всі обов’язкові поля.
3.10.1.3. ОІС повинна перевіряти формат поля "name" (максимум 60 символів). Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.10.1.4. ОІС повинна перевіряти наявність журналу з уже існуючим "class_id", "predmet_id" та не дозволяти створити дублікат. Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.10.1.5. ОІС повинна блокувати створення запису журналу, якщо в класі, для якого він створюється, немає учнів. При спробі створення або збереження такого запису рекомендується виводити для користувачів роз’яснювальне повідомлення.
3.10.1.6. ОІС повинна перевіряти, щоб учень не потрапив до двох різних підгруп. За збереження учня в одній із підгруп рекомендується візуально приховувати його для користувача при створенні наступної, щоб унеможливити невиконання цієї умови.
3.10.2. Вимоги до полів сутності підгрупи в журналах "Subgroup"
3.10.2.1. Вимоги до назви поля "унікальний номер підгрупи" - "subgroup_id".
3.10.2.2. Вимоги до назви поля "ID класу" - "class_id".
3.10.2.3. Вимоги до назви поля "ID предмета" - "predmet_id".
3.10.2.4. Вимоги до назви поля "назва підгрупи" - "name".
3.10.3. Вимоги до дій із підгрупами в журналах "Subgroup"
3.10.3.1. Для перегляду даних про окрему підгрупу використовується дія - "view" (/subgroup/view?id=902), де id - унікальний номер запису підгрупи, інформація про яку переглядається.
3.10.3.2. Для перегляду інформації про всіх учнів у окремій підгрупі використовується дія - "subgroup-students" (/journal/update?id=3698), де id - унікальний номер запису підгрупи.
3.11. Вимоги до сутності уроки закладу освіти "Lesson"
3.11.1. Загальні дані сутності уроки закладу освіти "Lesson"
3.11.1.1. ОІС повинна формувати урок із раніше створених сутностей.
3.11.1.2. Поле дати проведення уроку "lesson_date" (формат "dd.mm.yyyy") повинно бути актуальним у рамках обраного навчального періоду "semester_id". Рекомендується забороняти введення значення "lesson_date", яке не задовольняє цій умові, ще на етапі створення запису.
3.11.1.3. ОІС повинна перевіряти поле "lesson_topic" на кількість символів (максимум 1500 символів). Внесення до бази записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.11.1.4. ОІС повинна перевіряти поле "lesson_number_in_plan", має бути ціле число, кількість символів - 4. Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.11.1.5. ОІС повинна перевіряти поле "lesson_description", має містити максимум символів - 150. Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.11.1.6. ОІС повинна перевіряти поле "hometask" на кількість символів (максимум 500 символів). Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.11.1.7. Типи уроків можна отримати за посиланням: https://aikom-api.iea.gov.ua/v1/lesson/lesson-type-list.
3.11.1.8. Для передання домашнього завдання створюється стовпчик у журналі з відповідним типом (lesson_type_id =133 Домашнє завдання).
3.11.2. Вимоги до полів сутності уроки закладу освіти "Lesson"
3.11.2.1. Вимоги до назви поля "унікальний номер уроку" - "schedule_id".
3.11.2.2. Вимоги до назви поля "ID викладача" - "personal_id".
3.11.2.3. Вимоги до назви поля "ID класу" - "class_id".
3.11.2.4. Вимоги до назви поля "ID підгрупи" - "subgroup_id".
3.11.2.5. Вимоги до назви поля "ID приміщення" - "room_id".
3.11.2.6. Вимоги до назви поля "ID дзвінка" - "buzzer_id".
3.11.2.7. Вимоги до назви поля "ID предмета" –"predmet_id".
3.11.2.8. Вимоги до назви поля "ID типу уроку" - "lesson_type_id".
3.11.2.9. Вимоги до назви поля "дата проведення уроку" - "lesson_date".
3.11.2.10. Вимоги до назви поля "тема уроку" - "lesson_topic".
3.11.2.11. Вимоги до назви поля "опис уроку" - "lesson_description".
3.11.2.12. Вимоги до назви поля "№ уроку за календарним планом" - "lesson_number_in_plan".
3.11.2.13. Вимоги до назви поля "домашнє завдання" - "hometask".
3.11.2.14. Вимоги до назви поля "ID уроку, на який задано домашнє завдання" - "hometask_to".
3.11.3. Обов’язкові поля сутності уроки закладу освіти "Lesson"
3.11.3.1. Поле "ID викладача" - "personal_id".
3.11.3.2. Поле "ID класу" - "class_id".
3.11.3.3. Поле "ID приміщення" - "room_id".
3.11.3.4. Поле "ID дзвінка" - "buzzer_id".
3.11.3.5. Поле "ID предмета" - "predmet_id".
3.11.3.6. Поле "ID типу уроку" - "lesson_type_id".
3.11.3.7. Поле "дата проведення уроку" - "lesson_date".
3.11.4. Вимоги до дій з уроками закладу освіти "Lesson"
3.11.4.1. Для перегляду даних про окремий урок використовується дія - "view" (/lesson/view?id=1385), де id - унікальний номер запису уроку, інформація про який переглядається.
3.11.4.2. Для перегляду даних про всі уроки використовується дія - "index" (/lesson/index), інформацію в рамках дії-запиту можна відфільтрувати за всіма полями, що використовуються у властивостях уроку (/lesson/index?lesson_date= 2021-01-01).
3.11.4.3. Для редагування даних про окремий урок використовується дія - "update" (/lesson/update?id=1777), де id - унікальний номер запису уроку, який редагується.
3.11.4.4. Для перегляду списку всіх уроків використовується дія - "lesson-type-list" (/lesson/lesson-type-list).
3.11.4.5. Для видалення запису використовується дія - "delete" (/lesson/delete?id=1777), де id - унікальний номер запису уроку, який видаляється.
3.12. Вимоги до сутності уроки закладу освіти "Mark"
3.12.1. Загальні дані сутності уроки закладу освіти "Mark"
3.12.1.1. ОІС повинна перевірити наявність заповнення всіх обов’язкових полів.
3.12.1.2. Із переліком усіх типів оцінок і відміток можна ознайомитися за посиланням: https://aikom-api.iea.gov.ua/v1/mark/mark-value-list.
3.12.1.3. ОІС повинна перевіряти поле "comment" на кількість символів (максимум 300 символів). Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.12.1.4. У ОІС можна виставити оцінки тільки з переліку, сформованого згідно на підставі інформації за посиланням: https://aikom-api.iea.gov.ua/v1/mark/mark-value-list.
3.12.2. Вимоги до полів сутності уроки закладу освіти "Mark"
3.12.2.1. Вимоги до назви поля "унікальний номер оцінки" - "mark_id".
3.12.2.2. Вимоги до назви поля "ID уроку" - "schedule_id".
3.12.2.3. Вимоги до назви поля "ID учня" - "student_id".
3.12.2.4. Вимоги до назви поля "ID класу" - "class_id".
3.12.2.5. Вимоги до назви поля "ID викладача" - "personal_id".
3.12.2.6. Вимоги до назви поля "ID оцінки" - "mark_value_id".
3.12.2.7. Вимоги до назви поля "коментар" - "comment".
3.12.3. Обов’язкові поля сутності уроки закладу освіти "Mark"
3.12.3.1. Поле "ID уроку" - "schedule_id".
3.12.3.2. Поле "ID учня" - "student_id".
3.12.3.3. Поле "ID класу" - "class_id".
3.12.3.4. Поле "ID викладача" - "personal_id".
3.12.3.5. Поле "ID оцінки" - "mark_value_id".
3.12.4. Вимоги до дій із уроками закладу освіти "Mark"
3.12.4.1. Для перегляду даних про всі оцінки використовується дія - "index" (/mark/index), інформацію можна фільтрувати за всіма полями (/mark/index?student_id=39072598).
3.12.4.2. Для створення нового запису використовується дія - "create" (/mark/create).
3.12.4.3. Для перегляду даних про окрему оцінку використовується дія - "view" (/mark/view?id=2829), де id - унікальний номер запису оцінки, інформація про яку переглядається.
3.12.4.4. Для редагування даних про окремий урок використовується дія - "update" (/mark/update?id=2829), де id - унікальний номер запису оцінки, яка редагується.
3.12.4.5. Для перегляду списку всіх оцінок, що доступні для виставлення, використовується дія - "mark-value-list" (/mark/mark-value-list).
3.12.4.6. Для видалення окремого запису використовується дія - "delete" (/lesson/delete?id= 1777), де id - унікальний номер запису оцінки, яка видаляється.
3.13. Вимоги до сутності персонал "Personnel"
3.13.1. Загальні дані сутності персонал "Personnel"
3.13.1.1. ОІС зберігає поля "personal_birth" у форматі дати "(dd.mm.yyyy)".
3.13.1.2. ОІС повинна перевіряти, щоб поля "firstname", "lastname", "patronymic" були написані українською мовою (максиму 36 символів). Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.13.1.3. ОІС повинна перевіряти "student_birth", щоб дата була актуальною. Внесення до бази даних записів, що не відповідають цій вимозі, має блокуватись ОІС на етапі створення або внесення даних до запису.
3.13.1.4. ОІС повинна перевіряти "sex", формат "(чоловіча "1", жіноча "0")".
3.13.1.5. ОІС повинна перевіряти "c_leave", формат "1" - вибув, "0" - навчається)".
3.13.2. Вимоги до полів сутності персонал "Personnel"
3.13.2.1. Вимоги до назви поля "унікальний номер персоналу" - "personal_id".
3.13.2.2. Вимоги до назви поля "ім’я вчителя" - "firstname".
3.13.2.3. Вимоги до назви поля "прізвище вчителя" - "lastname".
3.13.2.4. Вимоги до назви поля "по батькові" - "patronymic".
3.13.2.5. Вимоги до назви поля "ID професії" - "profession_id".
3.13.2.6. Вимоги до назви поля "дата народження" - "personal_birth".
3.13.2.7. Вимоги до назви поля "стать" - "sex".
3.13.2.8. Вимоги до назви поля "вибув" - "c_leave".
3.13.3. Обов’язкові поля сутності персонал "Personnel"
3.13.3.1. ОІС повинна обов’язково передавати ім’я вчителя - "firstname".
3.13.3.2. ОІС має обов’язково передавати прізвище вчителя - "lastname".
3.13.4. Вимоги до дій із персоналом "Personnel"
3.13.4.1. Для створення нового запису представника персоналу використовується дія - "create" (/personnel/create).
3.13.4.2. Для перегляду даних про окремого представника персоналу використовується дія - "view" (/personnel/view?id=5477387), де id - унікальний номер запису персоналу, інформація про який переглядається.
3.13.4.3. Для редагування даних про окремого представника персоналу використовується дія - "update" (/personnel/update?id=5477384), де id - унікальний номер запису представника персоналу, який редагується.
3.13.4.4. Для видалення запису окремого представника персоналу використовується дія - "delete" (видалення запису), де id - унікальний номер запису персоналу, який видаляється.