Инвентаризация Demo83 для курса

Статус: XML-выгрузка и доступные runtime-настройки проверены 20 сентября 2026 года. Runtime-инвентаризация выполнена только на чтение через V85.COMConnector под пользователем Администратор.

Исследованный экземпляр

• база: C:\AI-Course-Work\Demo83-Base;
• XML-исходники: C:\AI-Course-Work\Demo83-Sources\src\configuration;
• имя конфигурации: ДемонстрационноеПриложение;
• представление: «Демонстрационное приложение»;
• поставщик: Фирма "1С";
• версия конфигурации: 1.0.41.3;
• режим совместимости расширений: Version8_3_27;
• основной режим запуска: управляемое приложение;
• размер файловой базы на момент проверки: около 193,5 МиБ;
• объём выгрузки: 844 файла, 34,19 МиБ, из них 128 BSL-модулей и 586 XML-файлов;
• объём BSL-кода: 13 955 строк.
• платформа фактического пользовательского сеанса при runtime-проверке: 8.5.1.1302.

Режим совместимости — это подтвержденное свойство конфигурации, но не доказанная минимальная версия платформы курса. Матрицу платформ нужно проверить отдельно.

Статическая проверка выгрузки завершилась без ошибок. Получено одно предупреждение о неканоническом порядке типа Bot в Configuration.xml; оно не указывает на повреждение конфигурации и не блокирует исследование.

При первой проверке база была закрыта. Во время runtime-инвентаризации она была открыта тонким клиентом 8.5.1.1302. Смешивать одновременно подключение 8.3.27 и пользовательский сеанс 8.5.1 нельзя: файловая база отклонила соединение другой версии. Это нужно превратить в явную проверку платформы перед шагами курса.

Данные внутри базы

База содержит полноценный демонстрационный набор, а не только структуру конфигурации:

Объект	Записей
Контрагенты	14, включая 2 группы; 12 активных элементов
Товары	36
Организации	3
Склады	5
Заказы	20
Приходы товара	41
Расходы товара	106, из них 104 проведены
Поступления денег	23
Оплаты	19
Встречи	2 519
Хранимые файлы	15
Входящие / исходящие письма	1 / 2
Продажи, записи регистра	275
Товарные запасы, записи регистра	343
Взаиморасчёты, записи регистра	187
Узлы мобильного обмена	2

У 12 контрагентов заполнены телефоны, у 11 — электронная почта. Сами значения в отчёт не выгружались. Визуально данные соответствуют демонстрационному набору, но наличие контактных полей, писем и файлов всё равно должно явно проговариваться ученику.

Заказы распределены по состояниям:

• Открыт — 3;
• ВРаботе — 4;
• Выполнен — 3;
• Закрыт — 10.

Пользователи информационной базы

Обнаружены четыре пользователя:

• Администратор;
• Менеджер по закупкам;
• Менеджер по продажам;
• Продавец.

Для всех включена стандартная аутентификация и выключена аутентификация операционной системы. Подтверждён только предоставленный владельцем базы вход Администратор с пустым паролем. Пароли остальных пользователей не проверялись.

Состав конфигурации

В выгрузке обнаружены:

Объекты	Количество
Справочники	20
Документы	6
Общие модули	23
Отчёты	9
Обработки	14
Регистры сведений	6
Регистры накопления	3
Роли	5
Регламентные задания	7
HTTP-сервисы	2
Web-сервисы	1
Планы обмена	1
Боты	1

Признаков интегрированной БСП в именах и исходниках не найдено. Это конфигурация-пример возможностей платформы, а не типовая конфигурация и не учебный пример архитектуры БСП.

Подходящая сквозная цепочка

Для исследования существующего решения подходит цепочка:

Документ Заказ
    → ввод намерения покупателя, без проведения
    → Документ РасходТовара
    → ОбработкаПроведения
    → запрос по услугам и контроль остатков
    → регистры ТоварныеЗапасы, Продажи, Взаиморасчеты
    → отчёты об остатках, продажах и взаиморасчетах

Существенный факт: Заказ не имеет обработчика проведения и не формирует движения. Поэтому формулировка Заказ → регистры неверна. Центр практики по проведению — РасходТовара.

Модуль РасходТовара полезен для курса, потому что в одном локальном фрагменте есть:

• табличная часть;
• запрос к данным документа;
• различение товара и услуги;
• движения сразу по трём регистрам;
• управляемая блокировка при оперативном проведении;
• контроль отрицательных остатков;
• сообщения пользователю, привязанные к строкам формы.

Для первого read-only исследования эта цепочка подходит хорошо. Для первого изменения она слишком насыщенна: до обучения diff, проверкам и восстановлению агент не должен самостоятельно переписывать проведение.

Внешние и автоматические механизмы

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

Регламентные задания

В метаданных Use=true установлено для заданий:

• ОбновлениеИндексаППД;
• ОбновлениеИсторииДанных;
• ОбработкаБотов;
• СлияниеИндексаППД.

Ещё три задания имеют Use=false: обработка неотработанных заказов и два задания агрегатов продаж.

Runtime-проверка подтвердила тот же набор: все семь предопределённых заданий существуют в базе, четыре перечисленных задания имеют Use=true. У задания ОбработкаБотов пользователь выполнения не указан. Факт Use=true ещё не доказывает, что задание успело выполниться, но это уже не только свойство XML — это фактическая настройка базы.

Сетевые возможности

Обнаружены:

• отправка и получение почты через SMTP, IMAP и POP3;
• константы адресов, портов, пользователей и паролей почтовых серверов;
• настройки push-уведомлений, ключей и маркеров доступа;
• регистрация информационной базы и обмен сообщениями через систему взаимодействия;
• бот ОфисМенеджер;
• мобильный план обмена;
• два HTTP-сервиса, Web-сервис и XDTO-пакет.

Runtime-проверка без вывода самих значений показала:

• адрес SMTP заполнен, но пользователь и пароль SMTP пусты;
• адрес, пользователь и пароль POP3 заполнены;
• IMAP-реквизиты пусты, ИспользоватьIMAP=false;
• сертификат мобильного приложения iOS заполнен;
• код нового узла мобильного обмена заполнен;
• ИспользоватьPushУведомления=true, но отдельные провайдеры APNS, FCM, HPK и WNS выключены, а их ключи и маркеры пусты;
• информационная база не зарегистрирована в системе взаимодействия;
• работа с торговым оборудованием выключена.

Заполненный пароль POP3 и сертификат не публикуются и не передаются агенту. Даже если это демонстрационные значения официальной базы, контур нельзя объявлять очищенным, пока они не заменены заведомо фиктивными значениями либо соответствующие механизмы не исключены проверкой готовности.

HTTP- и Web-сервисы сами по себе не доступны извне, пока база не опубликована. Наличие или отсутствие публикации хранится вне базы и этой проверкой не подтверждено.

Локальные компоненты и запуск файлов

Обнаружены:

• встроенные native-компоненты печати штрихкодов;
• драйвер сканера штрихкодов;
• запуск сохранённого файла внешним приложением из формы списка хранимых файлов.

Эти механизмы не нужны в первых уроках и должны оставаться вне сценария.

Предварительный safety-gate

До допуска агента к изменениям нужно подтвердить в режиме 1С:

1. Подтверждено происхождение установленного демонстрационного набора и отсутствие добавленных вручную данных.
2. Выбран отдельный учебный пользователь или явно принято использование Администратор только в локальном контуре.
3. Заполненные POP3-реквизиты и мобильный сертификат заменены заведомо фиктивными значениями либо изолированы формальной проверкой.
4. Зафиксировано, что база не зарегистрирована в системе взаимодействия.
5. Проверено, что база нигде не опубликована как HTTP- или Web-сервис.
6. Второй узел мобильного обмена проверен и не связан с внешним контуром.
7. На время базового курса отключено регламентное задание обработки ботов; остальные задания классифицированы по ожидаемому эффекту.
8. Внешние компоненты и торговое оборудование не используются в сценариях первых уроков.
9. Версия платформы курса зафиксирована, а одновременное подключение другой версии исключено.
10. Создан 00-Demo83-original.dt, а его восстановление проверено на отдельной тестовой базе.

Пока пункты 1–7 не закрыты, состояние контура — BLOCKED для автономных изменений агента. XML-исходники уже пригодны для read-only исследования.

Что ещё не проверено

• происхождение всех 15 хранимых файлов и трёх почтовых записей;
• заведомая фиктивность заполненных POP3-реквизитов и мобильного сертификата;
• назначение второго узла мобильного обмена;
• факт хотя бы одного выполнения включённых регламентных заданий;
• наличие публикаций базы;
• минимальная и рекомендуемая версия платформы;
• создание и контрольное восстановление обоих .dt;
• время повторяемой выгрузки и восстановления;
• поддерживаемый способ автоматической проверки готовности.

Эти пункты нельзя засчитать по исходникам. Они должны стать отдельными проверяемыми действиями урока 2.