Учётный контур
1С:Университет или 1С:Колледж может быть источником для контингента, учебных планов, расписания и связанных справочников.
Нужно настроить обмен или устранить расхождения между Moodle и 1С? Напишите, какие версии используете, какие данные должны передаваться и что сейчас не работает.
Обсудить задачу по 1С и Moodle
ЭИОС вуза на связке Moodle и 1С объединяет учебный и учётный контуры по согласованным правилам. Главный вопрос проекта — не только как передать запись, но и какая система отвечает за её актуальность, кто разбирает расхождения и когда результат можно принять. Ниже — шаблон матрицы данных и сверки, а не обещание готового коннектора для любой версии.
Связываем Moodle с 1С через согласованные интерфейсы и регламенты обмена: контингент, учебные планы и результаты обучения. Для выбора архитектуры используйте техническую дорожную карту интеграции LMS и 1С; для работ по отдельным системам — внедрение 1С:Университет ПРОФ и внедрение Moodle.
Единый контур нужен вузу или колледжу, когда учётные данные и учебная работа живут в разных системах: в 1С ведутся контингент и учебные планы, а в Moodle — курсы, задания и результаты обучения. Цель проекта — согласовать, какие данные передаются между контурами, кто отвечает за их актуальность и как проверяются изменения до запуска.
1С:Университет или 1С:Колледж может быть источником для контингента, учебных планов, расписания и связанных справочников.
Moodle используется для курсов, заданий, тестов и фиксации результатов обучения. Направление передачи оценок и статусов согласуется в проекте.
Для каждого обмена фиксируются владелец данных, набор полей, доступы, периодичность и порядок обработки исключений.
Проектный шаблон: вуз хочет передавать контингент в Moodle и согласованные результаты обучения обратно в 1С. Направления ниже — пример для обсуждения, не описание готовой функциональности. Для каждого объекта назначьте владельца, идентификатор, допустимые изменения и способ сверки.
На узком экране таблицу можно прокрутить по горизонтали.
| Объект и направление | Кто подтверждает данные | Контроль перед приёмкой |
|---|---|---|
| Студент и статус 1С → Moodle | Учебный отдел; 1С предлагается как источник учётного статуса. Правила доступа в Moodle согласует владелец учебного процесса. | Сопоставление по устойчивому идентификатору, а не только ФИО или email; перевод, повторное зачисление и изменение статуса не создают дубль. |
| План, дисциплина и курс 1С → Moodle | Учебно-методическое управление подтверждает план, команда Moodle — связь с курсом и учебным периодом. | Есть явная таблица соответствий. Отсутствующий или неоднозначный курс попадает в разбор, а не связывается автоматически по похожему названию. |
| Результат обучения Moodle → 1С | Преподаватель и ответственный за ведомость согласуют, какой результат считается утверждённым. | Согласованы шкала и правила округления; повторная передача не дублирует результат, исправление не перезаписывает утверждённую ведомость без разрешённого сценария. |
| Ошибка и повтор обмена Оба направления | ИТ-служба отвечает за доставку, владелец процесса — за смысловое расхождение. | По журналу можно найти объект, причину ошибки и итог повтора; сбой доступности не трактуется как успешная синхронизация. |
Если требуется менять сам учётный процесс, выделите доработку 1С с отдельной приёмкой. При переносе базы сначала проверьте состав внедрения 1С:Университет ПРОФ. Для описания интерфейсов используйте техническое руководство по интеграции.
Матрица обменов расширяет матрицу владения данными: фиксирует, каким способом Moodle и 1С:Университет или 1С:Колледж передают друг другу контингент, учебные планы, доступы к курсам и результаты обучения, по каким идентификаторам сверяются записи и как обрабатываются ошибки. Проектный шаблон подходит для типового вуза или колледжа и уточняется на обследовании.
На узком экране таблицу можно прокрутить по горизонтали.
| Объект и направление | Триггер и частота | Формат и транспорт | Идентификатор записи | Обработка ошибок |
|---|---|---|---|---|
| Студент и статус 1С → Moodle | Изменение приказа о зачислении, отчислении или переводе; регламентная синхронизация раз в сутки | REST или SOAP-сервис 1С; JSON; аутентификация по сервисной учётной записи; поверх HTTPS | Сквозной идентификатор физлица из 1С; e-mail и СНИЛС как резервные атрибуты сверки | Расхождение фиксируется в журнале обмена, спорная запись не создаётся автоматически; уведомление ответственному в учебном отделе |
| План и учебный курс 1С → Moodle | Утверждение или изменение рабочего плана; перед началом семестра | Пакетная выгрузка через REST-сервис 1С; JSON; при необходимости — обмен файлами по регламенту | Код учебного плана и код дисциплины из 1С; связь с курсом Moodle через справочник соответствий | Отсутствующий курс в Moodle помечается для ручного создания; запись в журнале и уведомление владельцу процесса |
| Зачисление на курс и роль 1С → Moodle | После обмена контингентом и планом; регламентно ежедневно | Web-service Moodle (enrol_manual, core_enrol); JSON; токен сервисной учётной записи Moodle | Идентификатор пользователя Moodle (id или username), полученный из справочника соответствий | Повтор попытки по расписанию; при устойчивой ошибке — карточка в журнале с ответственным |
| Результат обучения Moodle → 1С | Закрытие ведомости или закрытие итогового задания в курсе | Web-service Moodle (core_grades) как источник; передача в REST-сервис 1С; JSON; HTTPS | Пара «идентификатор студента × код дисциплины/плана»; версия ведомости | Спорная оценка не переносится автоматически: подтверждение преподавателя и ответственного за ведомость |
| Справочники: подразделения, дисциплины 1С → Moodle | Изменение справочника; регламентно раз в сутки | Пакетная выгрузка через REST-сервис 1С; JSON | Код элемента справочника из 1С | Удалённые или переименованные элементы помечаются, не удаляются в Moodle до подтверждения владельца |
| Ошибка и повтор обмена Оба направления | Ошибка транспорта, авторизации, валидации или бизнес-правила | Журнал обмена в 1С и/или во внешней шине; уведомления по e-mail или в мессенджер по регламенту | Идентификатор пакета обмена; ссылка на исходную и целевую записи | Автоповтор с backoff; после N неуспехов — эскалация ответственному, ручное решение и повторный запуск |
Детальное описание интерфейсов и примеры вызовов — в техническом руководстве по интеграции Moodle и 1С:Университет. Регламент обмена согласуется на этапе обследования и оформляется приложением к договору внедрения.
В техническом контуре обычно проверяют изменения контингента и учебных планов, доступ к курсам, а также передачу согласованных результатов обучения и оценок. Подробную методику и варианты архитектуры смотрите в гайде по интеграции LMS и 1С:Университет; состав возможных обменов — в обзоре интеграций Moodle и 1С. Пример связки Moodle и 1С опубликован в кейсе НИУ МЭИ.
Когда учётный и учебный контуры работают отдельно и команде нужно согласовать обмен данными между 1С и Moodle: контингент, учебные планы, доступ к курсам и результаты обучения.
В типовом проекте связка передаёт контингент и статусы студентов, учебные планы и связь с курсами, зачисления и роли, а также утверждённые результаты обучения. Справочники подразделений и дисциплин синхронизируются регламентно. Точный состав фиксируется в матрице обменов под требования конкретного вуза.
Оценки передаются в 1С после закрытия ведомости или итогового задания в Moodle: web-service Moodle отдаёт оценки, REST-сервис 1С их принимает; спорные результаты подтверждаются преподавателем и ответственным за ведомость. Направление и правила описаны в строке «Результат обучения» в матрице обменов.
Основной идентификатор — сквозной идентификатор физлица из 1С; для сверки используются e-mail и СНИЛС как резервные атрибуты. Учебные планы и курсы связываются через справочник соответствий, который ведёт учебно-методическое управление. Полный перечень идентификаторов — в столбце «Идентификатор записи» матрицы обменов.
Ошибки транспорта, авторизации и валидации фиксируются в журнале обмена, повторяются по расписанию с backoff, а после нескольких неуспехов эскалируются ответственному. Спорные записи не создаются и не изменяются автоматически — они выносятся владельцу процесса. Подробнее — строка «Ошибка и повтор обмена» в матрице обменов.
В проекте рассматриваются Moodle и 1С:Университет либо 1С:Колледж. Состав данных уточняется при обследовании; в типовых сценариях это контингент, учебные планы, расписание, курсы и согласованные результаты обучения.
1С используется как учётный контур, Moodle — как учебный. Для каждого обмена команда фиксирует источник данных, направление передачи, владельца данных и порядок обработки исключений.
Обследование текущих систем и ролей, согласование архитектуры обменов, настройка интеграции, проверка сценариев и передача регламентов ответственным сотрудникам.
Проверяются согласованные сценарии работы с контингентом, учебными планами, доступом к курсам и результатами обучения. Точный набор зависит от утверждённой схемы обменов.
Целевую схему контура, перечень данных и направлений обмена, настройки ролей и доступов, результаты проверки сценариев и регламент взаимодействия после запуска.
Цель проекта — связать существующие учебный и учётный контуры. Необходимые изменения и границы работ определяются после обследования текущих систем и требований вуза.
ЭИОС закрывает до 6 из 8 компонентов показателя АП2 и собирает доказательную базу для аккредитационного мониторинга. Подробнее — аккредитация и проверки.
Рассчитать проект: цены CDO Global · контакты. Отвечаем в течение часа.
Единая связка Moodle с 1С:Университет: миграция, интеграции, поддержка.