Разработчик 1С: Enterprise — от основ до промышленной разработки

Введение в платформу 1С:Предприятие и роли разработчика

Зачем нужна платформа 1С:Предприятие

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

Важно сразу разделить два понятия:

Платформа 1С:Предприятие — это движок и набор технологий: сервер, клиенты, язык, механизмы работы с данными, формы, отчеты, права, интеграции.

Конфигурация — это прикладное решение (что именно делает программа): структура данных, документы, справочники, формы, бизнес-логика, отчеты.

Пользователь работает с конфигурацией, а конфигурация работает на платформе.

Полезные официальные материалы:

Технологии платформы 1С:Предприятие

Платформа 1С:Предприятие 8

Как устроена система: основные компоненты

Типовая рабочая система 1С состоит из нескольких частей.

!Общая схема: клиент → сервер 1С → база данных (или файловая база)

Информационная база

Информационная база (часто говорят инфобаза) — это место, где живут данные и прикладная логика конфигурации.

Распространенные варианты:

Файловая информационная база: данные хранятся в файле (обычно для небольших установок, обучения, одиночной работы).

Клиент-серверная информационная база: данные хранятся в СУБД (например, PostgreSQL или Microsoft SQL Server), а пользователи подключаются через сервер 1С (обычно для многопользовательской работы и промышленной эксплуатации).

Клиенты

Клиент — это то, чем пользуется человек для работы в программе.

Толстый клиент — полноценное приложение с широкими возможностями (в современном внедрении используется реже, но важно знать, что он существует).

Тонкий клиент — основной вариант для корпоративной работы: часть логики и интерфейса выполняется на стороне клиента, основная логика — на сервере.

Веб-клиент — работа в браузере без установки клиента, удобен для удаленного доступа.

Сервер 1С:Предприятия

Сервер 1С выполняет важные задачи:

выполняет серверный код и разделяет нагрузку между пользователями

управляет сессиями пользователей

запускает фоновые задания и регламентные операции

обеспечивает масштабирование (в том числе через кластер серверов)

СУБД

СУБД (система управления базами данных) — отдельная программа, которая отвечает за надежное хранение и выборку данных. В клиент-серверном варианте 1С использует СУБД как хранилище.

Конфигурация: из чего состоит прикладное решение

Конфигурация в 1С описывается через метаданные.

Метаданные — это описание структуры приложения: какие есть сущности (справочники, документы), какие у них реквизиты, какие формы ввода, какие отчеты, какие права доступа.

Основные объекты метаданных

Справочник — хранит относительно постоянные сущности: номенклатуру, контрагентов, склады.

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

Регистр — хранит данные для учета.

- Регистр накопления — учет количеств и сумм (остатки и обороты). - Регистр сведений — хранение произвольных сведений (например, цены на дату). - Регистр бухгалтерии — учет проводок (если используется бухгалтерская модель).

Отчет — получение аналитики и печатных форм.

Обработка — вспомогательный инструмент: загрузки, массовые изменения, сервисные операции.

Формы и интерфейс

Пользовательский интерфейс строится через формы. Форма — это экран (или набор экранов), на котором пользователь вводит и просматривает данные.

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

Язык и модули: где живет код

В 1С прикладная логика пишется на встроенном языке (часто говорят язык 1С). Код размещается в модулях.

Чтобы не возникало неопределенности, зафиксируем ключевые термины:

Модуль — контейнер с программным кодом.

Процедура — подпрограмма, которая выполняет действия, но не возвращает значение.

Функция — подпрограмма, которая возвращает значение.

Где встречается код:

модули объектов (логика конкретного справочника/документа)

модули форм (реакция на действия пользователя)

общие модули (переиспользуемые функции и процедуры)

модули сеанса/приложения (общая логика на уровне запуска)

Также важно разделять, где исполняется код:

на клиенте (в интерфейсе)

на сервере (в бизнес-логике и работе с данными)

Это влияет на производительность, безопасность и сетевую нагрузку.

Типичные задачи, которые решает разработчик 1С

Роль разработчика в 1С — это не только написание кода. Обычно это комбинация проектирования структуры данных, реализации бизнес-логики и поддержки эксплуатации.

Что делает разработчик

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

Делает пользовательские формы (удобный ввод и контроль данных)

Реализует бизнес-правила (проверки, расчеты, автоматизация)

Пишет отчеты и печатные формы

Обеспечивает права доступа и безопасную работу

Делает интеграции (обмены данными с другими системами)

Оптимизирует производительность (в том числе запросы к данным)

Участвует в обновлениях и релизном процессе

Роли в команде и границы ответственности

В реальных проектах 1С редко работает один человек. Важно понимать роли, чтобы правильно взаимодействовать и не путать ответственность.

| Роль | Основная зона ответственности | Результат работы | |---|---|---| | Разработчик 1С | Реализация требований в конфигурации: метаданные, формы, код, отчеты, интеграции | Рабочий функционал в коде и метаданных | | Аналитик 1С | Сбор и формализация требований, описание процессов, постановки задач | ТЗ/User Story, модели процессов, критерии приемки | | Архитектор 1С | Техническая концепция: структура подсистем, интеграции, производительность, стандарты | Архитектурные решения, принципы разработки | | Консультант/внедренец 1С | Настройка, обучение пользователей, методическая поддержка | Настроенная система и обученные пользователи | | Администратор 1С | Инфраструктура: сервер, кластер, обновления платформы, резервное копирование | Стабильная работа среды | | Тестировщик (QA) | Проверка качества, регресс, сценарии, нагрузочные проверки (при необходимости) | Подтвержденное качество релиза |

На практике один человек может совмещать несколько ролей, особенно в малых командах. Но при росте системы разделение ролей становится критичным.

Как обычно выглядит цикл разработки в 1С

Ниже — упрощенный жизненный цикл задачи от идеи до релиза.

Требование

Проектирование (данные, интерфейсы, алгоритмы)

Разработка

Тестирование

Релиз в рабочую среду

Поддержка и улучшения

!Жизненный цикл задачи: от требования до поддержки

Инструменты разработчика

Для работы с 1С важно понимать два базовых инструмента.

Конфигуратор — встроенная среда разработки и администрирования конфигурации: метаданные, формы, модули, отладка.

1C:Enterprise Development Tools (EDT) — современная среда разработки на базе Eclipse, удобна для командной разработки и интеграции с системами контроля версий.

Дополнительно (в следующих темах курса будем разбирать подробнее):

системы контроля версий (например, Git)

средства сборки и доставки (CI/CD)

стандарты кодирования и форматирования

инструменты диагностики производительности

Официальная страница EDT:

1C:Enterprise Development Tools

Что будет дальше в курсе

Чтобы двигаться от основ к промышленной разработке, дальнейшие темы логично выстроить так:

установка и настройка среды разработки

устройство конфигурации и базовые объекты метаданных

формы, события, модули и встроенный язык

запросы и работа с данными

права, роли, разделение доступа

интеграции и обмены

производительность, диагностика и типичные ошибки

командная разработка, стандарты и релизный процесс

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

Проведение документов и бизнес-логика: движения по регистрам и контроль

Связь с предыдущими темами курса

Ранее мы уже разобрали:

как проектировать данные через справочники, документы и регистры;

как писать код на встроенном языке и разделять его по клиенту и серверу;

как получать данные запросами и почему регистры и их виртуальные таблицы важны для производительности;

как устроены управляемые формы и почему форма не должна быть единственным местом бизнес-правил.

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

!Схема жизненного цикла: документ → проведение → движения → регистры → итоги и отчеты

Что такое проведение документа

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

Термины, которые дальше будут использоваться постоянно:

Документ — хранит факт события и его детали.

Регистр — хранит учетный результат так, чтобы итоги получались быстро.

Движение — запись, которую документ добавляет в регистр при проведении.

Набор записей регистра — программный объект для записи строк в регистр.

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

Важно различать:

Запись документа сохраняет сам документ.

Проведение документа отражает влияние документа на учет.

На практике документ может быть:

записан, но не проведен;

проведен (и тогда его движения участвуют в расчетах остатков и оборотов).

Зачем движения по регистрам, а не расчеты “по документам”

Если вы пытаетесь получать остатки, обороты, себестоимость или другие итоги путем суммирования табличных частей документов, вы почти неизбежно получите:

тяжелые запросы;

сложные соединения;

рост времени формирования отчетов;

проблемы с перепроведением и изменениями задним числом.

Регистры решают эту проблему архитектурно:

документы создают движения;

регистры хранят результат учета;

запросы к виртуальным таблицам регистров дают быстрые итоги.

Официальные страницы как точки входа в технологию:

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Где живет код проведения

В типовой прикладной разработке логика движений живет в модуле объекта документа в обработчике проведения.

Наиболее распространенная точка входа:

ОбработкаПроведения(Отказ, РежимПроведения)

Ключевые свойства проведения как контекста:

проведение выполняется на сервере;

проведение должно быть детерминированным относительно данных документа;

проведение должно быть идемпотентным: повторное проведение должно приводить к корректному итоговому состоянию учета.

Минимальная модель: документ “Реализация” и регистр остатков

Рассмотрим учебно-производственный пример:

документ РеализацияТоваров списывает товары со склада;

регистр накопления ТоварыНаСкладах хранит остатки.

Типовая структура регистра накопления остатков:

измерения: Склад, Номенклатура;

ресурсы: Количество, Сумма.

Движение расхода уменьшает остаток.

!Анатомия движения по регистру накопления

Алгоритм промышленного проведения

Надежный подход к проведению обычно укладывается в последовательность:

Проверить заполненность и непротиворечивость реквизитов документа.

Подготовить данные для движений.

Выполнить контроль ограничений учета.

Сформировать движения.

Записать движения.

Важно: контроль и движения должны быть на сервере. Проверки на форме полезны для UX, но не могут считаться защитой.

Проверки перед движениями: где и какие

Проверки бывают двух типов:

структурные: заполнены обязательные реквизиты, корректны типы и диапазоны;

учетные: хватает остатка, не нарушены лимиты, доступен период, разрешено проведение.

Где размещать:

структурные проверки лучше начинать на форме для удобства, но обязательно дублировать в модуле объекта (например, в ПередЗаписью);

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

Пример структурной проверки в модуле объекта:

Формирование движений через коллекцию Движения

В модуле объекта документа платформа предоставляет объект Движения, через который обычно формируют движения регистров.

Упрощенный пример проведения реализации (расход по складу):

Что важно в этом шаблоне:

Записывать = Истина включает запись движений по регистру;

Добавить() создает новую запись движения;

Период обычно равен дате документа;

ВидДвижения определяет приход или расход.

Контроль остатков: как делать правильно

Самая частая учетная проверка — не допустить отрицательных остатков.

Наивная ошибка:

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

Правильный промышленный подход:

собрать список номенклатуры;

одним запросом получить остатки по всем позициям;

сравнить с потребностью документа;

при нехватке — отказать в проведении.

Получение остатков одним запросом

Ниже пример серверной функции, которую удобно вынести в общий модуль СкладСервер с директивой &НаСервереБезКонтекста.

Проверка “потребность против остатка”

В проведении документа вы:

Формируете массив номенклатуры из табличной части.

Получаете остатки одним вызовом.

Считаете потребность по документу.

Сравниваете.

Пример фрагмента внутри ОбработкаПроведения:

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

Транзакционность и целостность учета

Проведение — критичная операция, потому что вы меняете учетные итоги. У вас должен быть принцип:

либо движения сформированы и записаны корректно;

либо проведение не должно оставить “полусостояний”.

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

Базовые операции транзакций во встроенном языке:

НачатьТранзакцию()

ЗафиксироватьТранзакцию()

ОтменитьТранзакцию()

Практическое правило:

не усложняйте проведение транзакциями без необходимости;

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

Перепроведение и “идемпотентность” проведения

В промышленной базе документ может перепроводиться:

из-за изменения документа;

из-за изменений задним числом;

из-за восстановления после ошибок;

из-за регламентных операций.

Поэтому логика проведения должна быть устроена так, чтобы повторное проведение давало корректный результат.

Обычно это достигается платформенным механизмом:

движения документа связаны с регистратором;

при перепроведении старые движения заменяются новыми.

Практический вывод:

делайте движения полностью на основании текущего состояния документа;

не “дописывайте” движения поверх старых без необходимости;

избегайте скрытых зависимостей от UI и временных реквизитов формы.

Где размещать бизнес-логику, связанную с проведением

Чтобы проведение оставалось поддерживаемым, полезно разделять ответственность:

модуль объекта документа: оркестрация проведения, формирование движений;

общий модуль на сервере без контекста: сервисные функции (остатки, цены, проверки, расчеты);

форма: только запуск команды и удобные проверки.

Типовая архитектурная схема:

форма вызывает стандартное проведение;

документ в ОбработкаПроведения вызывает сервисы;

сервисы выполняют запросы и возвращают данные.

Типичные ошибки в проведении и как их избегать

Ошибка: учетные проверки только на форме

Последствия:

правило можно обойти записью/проведением из обработки, обмена или внешнего соединения.

Как правильно:

важные проверки размещать в ПередЗаписью и ОбработкаПроведения.

Ошибка: запрос в цикле по строкам

Последствия:

резкое падение производительности;

рост нагрузки на сервер и СУБД.

Как правильно:

один запрос на весь набор строк;

использование В (...) и параметров.

Ошибка: смешивание движений и “побочных эффектов”

Пример:

во время проведения менять справочники, создавать другие документы, делать интерактивные сообщения.

Как правильно:

проведение должно быть предсказуемым и максимально “чистым”;

интерактивность оставлять форме;

сложные процессы выносить в отдельные обработки или фоновые задания.

Ошибка: отсутствие внятного сообщения при отказе

Промышленная практика:

при отказе в проведении пользователь должен понимать что исправить;

сообщение должно содержать контекст: номенклатуру, требуемое количество, доступный остаток.

Мини-чеклист для промышленного проведения

Перед тем как считать проведение готовым, проверьте:

проведение выполняется только на сервере, без UI-зависимостей;

документ можно перепровести без “разъезда” итогов;

все критичные проверки есть в модуле объекта, а не только на форме;

нет запросов в цикле, используется пакетная выборка;

движения формируются по всем нужным регистрам и только при успешном контроле;

сообщения об отказе понятны пользователю и помогают исправить данные.

Что дальше по курсу

После того как вы научились проводить документы и формировать движения, следующий шаг к промышленной разработке — закрепить тему в интерфейсе и аналитике:

сделать удобные формы документа и списка;

построить отчеты по регистрам (СКД) и сверить итоги с проведением;

добавить печатные формы, которые отображают уже корректные данные документа.

Это замыкает полный контур: документ → проведение → регистры → запросы/отчеты → печать.

Обмены данными: планы обмена, универсальный формат, XML/JSON

Как тема связана с предыдущими статьями курса

Ранее мы построили базовую «промышленную цепочку» разработки в 1С:

спроектировали данные через справочники, документы, регистры;

распределили код по модулям и контекстам клиент/сервер;

научились получать данные запросами и оформлять результат как отчеты и печатные формы;

разобрали проведение документов как механизм, который делает учет надежным.

Обмены данными продолжают эту линию: как переносить и синхронизировать те же самые сущности и учетные факты между базами 1С и внешними системами.

На практике обмены встречаются почти везде:

интернет-магазин и 1С (заказы, остатки, цены);

CRM и 1С (контрагенты, сделки, оплаты);

распределенные базы (филиалы, магазины) с периодической синхронизацией;

интеграции через API, файлы, очереди.

!Общая картина: из каких слоев обычно состоит обмен данными

Базовые понятия: интеграция, синхронизация, формат и транспорт

Чтобы дальше не путаться, разделим термины.

Интеграция: система А передает данные системе Б так, чтобы они были использованы в процессе.

Синхронизация: обе системы могут менять данные, и нужно поддерживать их согласованность.

Формат данных: как именно описаны данные в сообщении (например, XML или JSON).

Транспорт: как именно сообщение доставляется (например, файл на диске, HTTP-запрос).

Практическая привычка разработчика 1С: сначала зафиксировать что передаем (модель данных и события), затем как упаковываем (формат), и только потом как доставляем (транспорт).

Планы обмена: что это и когда они нужны

План обмена в 1С — это объект метаданных, предназначенный для организации обмена между информационными базами, прежде всего в сценариях, где важны:

узлы обмена (кто с кем обменивается);

регистрация изменений (что изменилось с прошлого раза);

пакетирование сообщений (как собрать изменения в порцию для отправки);

идемпотентность обработки (повторно пришедшее сообщение не должно ломать данные).

Когда планы обмена подходят лучше всего

Планы обмена обычно уместны, когда:

у вас две и более базы 1С, которые должны обмениваться «порциями»;

требуется обмен изменениями, а не «полная выгрузка всего каждый раз»;

важна история обмена (что и когда отправили, что приняли);

возможны разрывы связи и обмен «догоняющими» пакетами.

Примеры:

центральная база и филиалы;

кассы/магазины и центральный учет;

автономная работа с периодической синхронизацией.

Что такое узлы обмена

Узел обмена — это участник обмена. Обычно есть:

главный узел (центральная база);

подчиненные узлы (филиалы).

Важно понимать: план обмена описывает логическую схему обмена (кто участники и как фиксируются изменения), а доставка сообщений может быть разной.

Регистрация изменений: ключевой промышленный механизм

Главная ценность планов обмена — регистрация изменений.

Идея простая:

Пользователь или алгоритм изменил объект (например, элемент справочника).

Платформа зарегистрировала факт изменения в контуре обмена.

При очередной выгрузке мы отправляем только то, что изменилось.

Почему это важно:

не перегружаем сеть и приемник;

ускоряем обмен;

можно строить обмен как «инкрементальный».

Практическое правило: если вы проектируете обмен как регулярный и долгоживущий, почти всегда потребуется инкрементальность.

Что план обмена не решает автоматически

План обмена — мощный механизм, но он не снимает с разработчика ответственность за:

правила сопоставления данных (идентификация объектов, ключи);

конфликты изменений (кто победит, если изменили в двух местах);

версионирование формата сообщений;

обработку ошибок и повторов;

безопасность (аутентификация, авторизация, защита канала).

Универсальный формат обмена: идея и зачем он нужен

Универсальный формат обмена — это подход, при котором сообщения описываются не «под конкретную форму/таблицу/экран», а как универсальные сущности предметной области с устойчивыми правилами идентификации и структуры.

Цели универсального формата:

уменьшить количество уникальных интеграций «точка-точка»;

сделать формат более устойчивым к развитию конфигурации;

унифицировать правила:

- идентификации объектов; - представления ссылок; - передачи табличных частей; - обработки удалений и пометок удаления; - передачи изменений.

Что обычно входит в «универсальность»

На уровне архитектуры универсальный формат обычно включает:

тип сущности (что это: номенклатура, контрагент, документ);

устойчивый идентификатор (чтобы приемник понял, какой именно объект обновлять);

версию сообщения (чтобы новые поля не ломали старых потребителей);

набор реквизитов и набор строк (табличные части);

признаки состояния (например, удален/активен).

Универсальный формат и планы обмена

Эти идеи дополняют друг друга:

план обмена отвечает за что изменилось и как порционировать;

универсальный формат отвечает за как описать изменения в сообщении.

XML и JSON как форматы данных

XML и JSON — это два самых распространенных текстовых формата сериализации.

Официальные источники по форматам:

Спецификация XML на сайте W3C

Описание формата JSON

Ключевые различия XML и JSON

| Критерий | XML | JSON | |---|---|---| | Представление | теги и атрибуты | объекты и массивы | | Типичное применение | сложные стандартизованные документы, исторически много корпоративных форматов | API, веб-интеграции, легкие сообщения | | Читаемость человеком | средняя (много служебных тегов) | обычно выше | | Размер сообщений | часто больше | часто меньше | | Схемы и строгая валидация | часто используется (XSD) | возможно, но реже и не так стандартно |

Практический вывод для 1С-проектов:

если вы делаете интеграцию с веб-сервисами и API, чаще выбирают JSON;

если вы работаете со стандартизованными «документными» обменами или историческими требованиями, часто встречается XML.

Сериализация и десериализация в 1С: общая идея

Под сериализацией понимают преобразование данных в текстовый формат (XML/JSON) для передачи.

Под десериализацией понимают обратное преобразование: текст → структуры данных 1С.

В 1С удобно придерживаться «промышленного контура»:

на сервере:

- собрать данные одним запросом или минимальным числом запросов; - сформировать структуру данных (например, Структура, ТаблицаЗначений); - сериализовать в XML/JSON;

на клиенте:

- только запуск обмена и показ статуса, без тяжелой обработки.

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

Пример: подготовка сообщения в JSON из структуры данных

Ниже пример типовой подготовки «пакета» данных на сервере: сначала формируем Структура, затем записываем JSON.

Что важно в этом шаблоне:

функция сделана без контекста, чтобы не зависеть от формы;

внутри собирается «универсальное» представление сущности;

на выходе возвращается строка JSON, пригодная для транспорта (HTTP, файл, очередь).

Пример: чтение JSON и разбор в структуру

Пример обратной операции: получаем строку JSON, превращаем в данные 1С.

Промышленная рекомендация: входящие сообщения всегда валидируйте на уровне «контракта», даже если источник кажется доверенным:

обязательные поля;

ожидаемые типы;

допустимые значения.

XML в 1С: когда нужен и как о нем думать

XML часто используют, когда:

интеграция требует строгой структуры документа;

существует внешний стандарт XML;

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

Внутренний принцип для разработчика 1С тот же:

сначала сформировать структуру данных;

затем сериализовать в XML;

не выполнять запросы «в цикле по тегам».

Если формат ваш собственный, чаще выгоднее JSON из-за простоты и меньшего объема.

Планы обмена: промышленная логика работы (без привязки к транспорту)

Ниже — концептуальная схема, которую полезно держать как «скелет».

Выгрузка изменений

Определяем узел-получатель.

Получаем список зарегистрированных изменений для этого узла.

Готовим сообщения (пакеты) в выбранном формате.

Отправляем через выбранный транспорт.

Фиксируем факт успешной отправки.

Загрузка изменений

Получаем пакет сообщения.

Разбираем формат (XML/JSON).

Сопоставляем сущности с объектами приемника.

Применяем изменения.

Фиксируем факт успешной обработки.

!Жизненный цикл изменений в обмене и где должен выполняться код

Идемпотентность и повторы

В обменах почти неизбежны повторы:

сеть «упала» после отправки;

приемник принял сообщение, но не успел подтвердить;

пакет пришел дважды.

Промышленный подход:

каждое сообщение должно иметь идентификатор;

приемник должен уметь понять, что это уже обработано;

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

Идентификация данных: главная сложность обменов

Внутри одной базы ссылка на объект однозначна. Между базами — нет.

Поэтому нужно договориться, как объект узнается в приемнике.

Типовые стратегии:

единый устойчивый идентификатор

- часто используют уникальный идентификатор объекта (если система так спроектирована);

бизнес-ключ

- например, ИНН+КПП для контрагента, артикул для товара;

таблица соответствий

- отдельное хранилище «идентификатор источника → ссылка приемника».

Практический вывод:

для промышленных обменов почти всегда нужна либо таблица соответствий, либо четкий бизнес-ключ;

полагаться только на «наименование» как ключ обычно нельзя.

Версионирование формата: как не сломать интеграцию при развитии

Системы меняются: добавляются реквизиты, табличные части, новые сущности.

Чтобы обновления не ломали обмен:

добавляйте в сообщение поле ВерсияФормата;

новые поля делайте необязательными, если это возможно;

на приемнике корректно обрабатывайте «неизвестные поля» (игнорировать или логировать);

фиксируйте контракт формата как документ команды.

Минимальная практика:

версия — строка, например "1.0";

обработчики на приемнике могут ветвиться по версии.

Производительность обменов: правила, которые предотвращают деградацию

Эти правила напрямую продолжают темы про запросы, проведение и клиент-сервер.

Один запрос вместо запросов в цикле

Плохо:

для каждой строки сообщения искать данные в базе отдельным запросом.

Хорошо:

собрать список ключей и одним запросом получить нужные данные;

построить Соответствие и обращаться к нему в памяти.

Минимизируйте клиент-серверные вызовы

Плохо:

запускать обмен из формы так, что на каждый элемент сообщения идет отдельный вызов на сервер.

Хорошо:

один серверный вызов: принять пакет → разобрать → применить.

Делайте тяжелое на сервере

Сериализация, разбор больших сообщений, применение изменений, запросы — это серверная зона ответственности.

Клиенту оставляйте:

запуск;

индикацию прогресса;

показ результата.

Безопасность обменов: минимальный обязательный слой

Даже учебный обмен полезно проектировать с правильными привычками.

Аутентификация: кто именно отправляет сообщение.

Авторизация: что именно этому отправителю разрешено.

Валидация входных данных: нельзя доверять входному JSON/XML.

Журналирование: что приняли и что применили.

Если транспорт HTTP, то промышленная база обычно требует защищенный канал (например, TLS) и четкие учетные данные.

Как выбрать подход: краткая памятка

| Задача | Что чаще выбрать | |---|---| | Распределенные базы 1С, обмен изменениями | план обмена + инкрементальная регистрация | | Интеграция с веб-сервисом/REST API | JSON + HTTP | | Интеграция по стандарту, документный формат | XML | | Долгоживущая интеграция с развитием структуры | универсальный формат + версионирование |

Что дальше по курсу

Обмены — это место, где сходятся почти все темы:

модель данных определяет что передавать;

клиент-сервер влияет на где обрабатывать;

запросы и регистры влияют на как быстро готовить пакеты;

печать и отчеты часто требуют согласованных данных после обмена.

Логичное продолжение практики:

реализовать минимальный обмен сущностями (например, номенклатура и цены);

добавить регистрацию изменений и пакетирование;

сделать обработку ошибок и повторов;

проверить производительность: отсутствие запросов в циклах и лишних клиент-серверных вызовов.

Интеграции: HTTP-сервисы, REST, SOAP, COM и внешние источники данных

Связь с предыдущими темами курса

Ранее мы уже построили базовую «промышленную цепочку» разработки в 1С:

проектирование данных через справочники, документы, регистры;

распределение кода по модулям и контекстам клиент/сервер;

получение данных запросами и формирование результата через СКД, отчеты и печать;

проведение документов как способ обеспечить целостный учет;

обмены данными как синхронизация между системами через планы обмена, XML/JSON.

Интеграции логично продолжают обмены: если обмены часто про пакеты изменений и синхронизацию, то интеграции чаще про онлайн-взаимодействие и прямой доступ к данным/функциям через стандартизированные интерфейсы.

!Обзорный ландшафт интеграций: какие механизмы есть в 1С и куда они подключаются

Базовые понятия интеграций

Чтобы правильно выбрать механизм интеграции, полезно разделять несколько осей.

Контракт, формат и транспорт

Контракт API: что именно доступно, какие поля обязательны, какие коды ошибок, какие версии.

Формат данных: чаще всего JSON или XML.

Транспорт: чаще всего HTTP(S), реже файлы, очереди, специфические протоколы.

Полезные источники по базовым технологиям:

HTTP на MDN Web Docs

JSON (официальное описание)

XML (W3C)

Онлайн-вызовы и пакетные обмены

Онлайн-интеграция: запрос → обработка → ответ (например, интернет-магазин спрашивает остаток прямо сейчас).

Пакетный обмен: набор изменений/документов передается порциями (например, раз в 5 минут).

Практический вывод: многие промышленные решения используют оба подхода одновременно.

HTTP-интеграции в 1С: входящие и исходящие

HTTP сегодня является основной «универсальной шиной» для интеграций.

Входящие HTTP: HTTP-сервисы 1С

HTTP-сервис в 1С — это механизм, позволяющий конфигурации принимать HTTP-запросы (обычно от внешних систем) и возвращать ответ.

Ключевые элементы модели:

URL/маршрут: по какому пути обращаются.

HTTP-метод: GET, POST, PUT, DELETE.

Тело запроса: обычно JSON или XML.

Коды ответа: 200, 201, 400, 401, 403, 404, 409, 500.

Практический принцип промышленной разработки:

обработчики HTTP-сервиса должны быть серверными;

входные данные должны валидироваться;

ошибки должны превращаться в предсказуемый ответ (код + сообщение + детали, если можно).

REST как стиль проектирования HTTP API

REST — не «протокол», а стиль: ресурсы, методы, предсказуемые URL, использование стандартных кодов ответа.

Таблица типичных соответствий:

| Цель | Метод | Пример URI | Идея ответа | |---|---|---|---| | Получить объект | GET | /api/items/{id} | 200 + JSON | | Получить список | GET | /api/items?changedSince=... | 200 + JSON | | Создать объект | POST | /api/items | 201 + JSON созданного | | Обновить объект | PUT | /api/items/{id} | 200 или 204 | | Удалить объект | DELETE | /api/items/{id} | 204 |

Источник по REST-подходу удобно держать как справочник:

HTTP-методы на MDN Web Docs

Исходящие HTTP: вызов внешних REST API из 1С

Для исходящих вызовов 1С выступает как клиент.

Промышленная структура такого вызова обычно включает:

подготовку данных (структуры/таблицы, сериализация в JSON);

установку заголовков (например, Authorization, Content-Type);

настройку таймаутов;

обработку кодов ответа;

логирование запросов и ошибок;

повторы с ограничением (если допустимо).

Важно связывать это с темой клиент/сервер: вызовы API должны выполняться на сервере, а форма должна только запускать действие и показывать статус.

SOAP и Web-сервисы: когда и зачем

SOAP — протокол обмена сообщениями на базе XML, часто встречается в корпоративных и «исторических» интеграциях.

Официальная спецификация:

SOAP 1.2 Part 1 (W3C)

Отличия SOAP от REST на практике

| Критерий | REST/JSON | SOAP/XML | |---|---|---| | Типичное использование | веб-API, мобильные приложения | корпоративные системы, гос/банки, легаси | | Формат | JSON (чаще), XML (иногда) | XML (обязательно) | | Контракт | часто через документацию, OpenAPI | часто через WSDL | | Ошибки | HTTP-коды + тело | SOAP Fault |

Когда SOAP оправдан

внешний контрагент предоставляет только SOAP;

есть строгий контракт WSDL и требуется совместимость;

интеграция уже существует и ее нельзя менять.

Промышленная рекомендация: если у вас есть выбор для новой интеграции, чаще проще поддерживать REST/JSON; SOAP оставляйте для случаев, где он задан внешней стороной.

COM-интеграции: где применяются и какие риски

COM — технология Windows для взаимодействия между приложениями и компонентами.

Справочная точка входа:

Что такое COM (Microsoft Learn)

Типовые сценарии COM вокруг 1С

1С управляет внешним приложением (например, Excel/Word) для формирования документов.

Внешнее приложение управляет 1С (например, сервис на Windows создает документы в базе через COM-коннектор).

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

Практические ограничения COM

COM обычно привязан к Windows и к окружению, где зарегистрированы компоненты.

COM-интеграции сложнее масштабировать и переносить.

Требуется аккуратная настройка прав, учетных записей, DCOM (в зависимости от схемы).

Промышленная рекомендация: COM применяйте там, где он действительно нужен по окружению или требованиям; для межсистемной интеграции между серверами чаще выбирают HTTP.

Внешние источники данных в 1С

Внешние источники данных — подход, когда 1С подключается к внешней базе данных и может получать данные из нее без предварительной загрузки в собственные справочники/документы.

Эта тема логически продолжает раздел про запросы: ключевой вопрос здесь не «как рисовать интерфейс», а «как безопасно и эффективно читать внешние данные и где проходит граница ответственности».

Зачем подключать внешний источник данных

нужно читать справочники/остатки из внешней системы без дублирования;

нужно строить отчет по внешним данным «как есть»;

нужен постепенный переход со старой системы, когда часть данных еще живет во внешней СУБД.

Риски внешних источников данных

производительность зависит от внешней СУБД и канала связи;

сложно обеспечить транзакционную целостность между 1С и внешней БД;

права доступа и безопасность усложняются: появляются учетные данные к внешней БД;

при изменении схемы внешней БД интеграция может «сломаться».

Промышленный принцип: внешний источник данных — это обычно источник чтения и аналитики, а не место, где стоит «вести учет» вместо регистров.

Архитектура интеграций: как сделать устойчиво

Ниже набор практик, которые напрямую следуют из прошлых тем курса: клиент/сервер, запросы, проведение, обмены.

Где должна жить интеграционная логика

Рекомендуемая схема слоев:

форма (клиент): запуск, параметры, индикация результата;

серверный сервис (общий модуль &НаСервереБезКонтекста): подготовка/разбор сообщений, вызовы внешних API, маппинг;

объекты данных (документы/справочники): обязательные проверки и целостность данных;

регистры: учетные итоги, которые не должны зависеть от того, откуда пришли данные.

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

Валидация входящих данных

Для входящих REST/SOAP запросов и файловых пакетов обязательно проверяйте:

наличие обязательных полей;

типы значений (строка/число/дата);

допустимость ссылок (существует ли объект или корректно ли создается);

ограничения предметной области (например, количество > 0).

Промышленная рекомендация: ошибки валидации должны возвращаться как предсказуемый ответ, а не как «падение» исключением без контекста.

Идемпотентность и повторы

Интеграции почти всегда сталкиваются с повторами запросов и сообщений.

Типовые причины:

клиент не получил ответ из-за таймаута и повторил запрос;

сеть оборвалась после отправки;

внешняя очередь доставила сообщение повторно.

Промышленная практика:

вводите идентификатор операции (например, ExternalRequestId);

храните факт обработки (например, регистр сведений «ЖурналИнтеграции»);

делайте операции применения изменений устойчивыми к повтору.

Безопасность: аутентификация, авторизация, защита канала

Минимальный обязательный слой для промышленной интеграции:

TLS для HTTP (HTTPS);

аутентификация (кто обращается): токен, Basic Auth, сертификат, OAuth (по требованиям);

авторизация (что разрешено): проверка прав роли/пользователя, запрет опасных операций;

журналирование: кто вызвал, когда, что сделал, какой результат.

Важно: даже если вы скрыли команду на форме, это не защита. Любая внешняя интеграция должна перепроверять права на сервере.

Таймауты, ретраи и «устойчивость под нагрузкой»

Практики, которые предотвращают деградацию:

задавайте таймауты на HTTP-запросы;

делайте ограниченные повторы только там, где операция безопасна;

не выполняйте тяжелые операции в одном синхронном вызове, если это может занять минуты;

для длительных сценариев используйте фоновые задания и возвращайте внешний статус.

Практические сценарии выбора технологии

Ниже — ориентиры, которые помогают быстро выбрать подход.

| Задача | Что чаще выбрать | Почему | |---|---|---| | Внешняя система должна получать данные «онлайн» | HTTP-сервис (REST/JSON) | просто, стандартизировано, удобно для веб | | Корпоративная система предоставляет только WSDL | SOAP (Web-сервис) | контракт задан внешней стороной | | Интеграция с приложением Windows (Excel/драйвер/легаси) | COM | зависит от Windows-компонентов | | Нужен доступ к данным внешней СУБД без загрузки | Внешний источник данных | прямое чтение, удобно для аналитики | | Нужна синхронизация изменений между базами 1С | планы обмена + формат (JSON/XML) | инкрементальность, регистрация изменений |

Типичные ошибки и как их избегать

Ошибка: интеграция пишет данные «мимо» бизнес-логики

Последствия:

документы записаны, но учет не отражен;

нет проверок, появляются некорректные данные;

отчеты расходятся.

Как правильно:

создавать/изменять объекты через корректные механизмы (запись, проведение);

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

Ошибка: запросы к базе выполняются «по одному на строку»

Последствия:

резкая деградация производительности;

рост нагрузки на СУБД.

Как правильно:

собирать ключи и делать один пакетный запрос;

использовать В (&Список) и параметры запроса;

использовать соответствия (Соответствие) для быстрых обращений в памяти.

Ошибка: отсутствие контрактов и версий

Последствия:

любое изменение реквизита ломает интеграцию;

невозможно безопасно развивать API.

Как правильно:

фиксировать контракт (поля, типы, обязательность);

версионировать API и формат;

быть обратно совместимым, где это возможно.

Что дальше по курсу

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

Дальнейшая практическая траектория развития навыка обычно такая:

выделить серверный «интеграционный слой» в общих модулях;

реализовать журнал интеграций (идентификаторы операций, статусы, ошибки);

добавить тестовые стенды и контракты (чтобы обновления не ломали внешние системы);

оптимизировать производительность: пакетные запросы, минимизация клиент-серверных вызовов, фоновые сценарии.

Расширения, переопределения и обновления типовых конфигураций

Связь с предыдущими темами курса

В предыдущих статьях мы разобрали архитектуру прикладного решения, модули и клиент-серверное разделение, запросы/СКД, проведение документов и интеграции. Эта тема переводит знания в практику промышленной разработки: большинство проектов в 1С строятся не «с нуля», а как развитие типовой конфигурации (например, бухгалтерии, УТ, ERP) с регулярными обновлениями от вендора.

Ключевая задача разработчика здесь не только сделать функциональность, но и сделать ее так, чтобы:

обновления типовой конфигурации ставились предсказуемо;

доработки не превращались в «вечный конфликт с типовой»;

команда могла сопровождать изменения годами.

!Слои, в которых обычно размещают доработки типовых решений

Официальные страницы как стабильные точки входа в технологию платформы:

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Базовые термины: что именно мы «обновляем» и что «дорабатываем»

Чтобы корректно говорить об обновлениях, важно различать несколько уровней.

Платформа: технологический движок (клиент, сервер, встроенный язык, механизмы данных).

Типовая конфигурация: прикладное решение поставщика (вендора), которое развивается релизами.

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

Поддержка: режим, когда конфигурация связана с конфигурацией поставщика и умеет обновляться.

Снятие с поддержки: отказ от механизма «поставщик → обновление», после чего обновляться становится существенно сложнее.

Главная практическая мысль: обновление — это не только «поменять код». Это изменение метаданных, структуры хранения, интерфейсов и поведения. Поэтому стратегия доработок должна быть совместима с будущими релизами.

Почему «просто поменять типовую» почти всегда приводит к проблемам

Прямая доработка объектов типовой конфигурации (правки модулей, форм, метаданных) выглядит самым быстрым способом, но имеет промышленную цену.

Что происходит при каждом обновлении типовой

Поставщик меняет те же объекты, которые вы доработали.

При обновлении появляются конфликты, которые нужно разбирать.

После слияния нужна регрессия: проверка критичных сценариев.

С каждым релизом объем конфликтов часто растет.

Типичные последствия

обновление превращается в отдельный мини-проект;

часть изменений «теряется» при слиянии;

повышается риск ошибок в учете;

растет стоимость сопровождения.

Отсюда промышленная цель: максимально вынести изменения из слоя типовой конфигурации.

Инструменты промышленной доработки типовых: что выбирать

В реальных проектах обычно комбинируют несколько подходов.

Сравнение подходов

| Подход | Где живет доработка | Влияние на обновления | Когда выбирать | |---|---|---|---| | Расширение конфигурации | в отдельном объекте Расширение | обычно минимальное | большинство «добавить/переопределить» без ломки типовой | | Внешние отчеты и обработки | отдельные файлы или объекты конфигурации | минимальное | сервисные функции, печать, разовые операции | | Подписки на события | общий модуль + объект подписки | обычно небольшое | кросс-объектные правила без правки типовых объектов | | Прямые доработки типовой | в основной конфигурации | максимальное | когда расширения недостаточно или нужна глубокая перестройка | | Отдельная (нетиповая) конфигурация | собственное решение | обновлений типовой нет | если типовая модель не подходит по архитектуре |

Практический вывод: в промышленной разработке расширение — основной инструмент «не ломать обновления», а прямые правки — крайний вариант.

Расширение конфигурации: что это и почему оно помогает

Расширение конфигурации — это механизм, позволяющий добавлять и переопределять функциональность типовой конфигурации без непосредственного изменения ее объектов.

Идея в том, что:

типовая конфигурация остается максимально близкой к поставщику;

ваш функционал находится в отдельном «слое»;

обновления типовой чаще проходят без конфликтов или с меньшим числом конфликтов.

Какие задачи чаще всего решают расширением

добавление реквизитов в справочники, документы и формы;

добавление новых команд и обработчиков;

изменение поведения через расширения модулей;

замена или расширение форм (в зависимости от задачи);

добавление новых объектов (справочники, обработки, отчеты) в своем слое.

Ключевое ограничение мышления

Расширение удобно, когда вы добавляете и локально переопределяете. Если же требуется «перепридумать» объект типовой (например, полностью другой жизненный цикл документа, другая модель учета, другой набор измерений регистров), расширение может оказаться недостаточным.

Переопределения: что именно можно менять и как делать это устойчиво

Под переопределением в типовых проектах обычно понимают изменение поведения без разрушения обновляемости.

Переопределение модулей через расширение

Промышленно безопасная цель: не копировать огромные фрагменты типового кода, а добавлять точечные изменения.

Практики, которые повышают устойчивость:

держать переопределение минимальным по объему;

выносить расчеты и правила в общий модуль своего расширения;

избегать зависимости от «внутренностей» типовых процедур, которые могут поменяться релизом.

Переопределение форм

С формами важно помнить клиент-серверные принципы из предыдущих тем.

Промышленная логика изменений формы:

Добавить реквизиты и элементы для нового UX-сценария.

Команду оставить на клиенте.

Бизнес-логику вынести на сервер в общий модуль &НаСервереБезКонтекста.

Критичные проверки продублировать на уровне объекта (если меняется запись/проведение).

Переопределение через подписки на события

Если правило должно применяться ко множеству типовых объектов, подписки на события часто лучше прямых правок.

Плюсы подхода:

меньше точек конфликта при обновлении;

кросс-объектные правила живут централизованно.

Минус подхода:

при плохой дисциплине подписки превращаются в «скрытую магию», из-за которой трудно понять причины поведения.

Практика: документируйте подписки и делайте имена обработчиков так, чтобы было видно назначение.

Поддержка типовой конфигурации: режимы и смысл

В конфигураторе у типовой конфигурации обычно есть связка с поставщиком. В терминах процесса это означает:

вы знаете, что такое «эталон» (конфигурация поставщика);

можете сравнивать изменения;

обновления применяются как управляемое слияние.

Почему важно не «снимать с поддержки» без необходимости

Когда конфигурацию снимают с поддержки, команда часто выигрывает «быстро сейчас», но платит «дорого потом»:

обновления становятся существенно сложнее;

теряется удобная механика сравнения и слияния;

повышается риск отстать от релизов (в том числе технологических и регламентных изменений).

Промышленное правило: если проект на типовой, цель обычно такая — максимально долго оставаться на поддержке.

Обновление типовой: как выглядит промышленный процесс

Надежное обновление — это управляемый процесс, а не разовая операция.

!Типовой промышленный цикл обновления

Рекомендуемый контур обновления

Подготовить тестовую копию базы и резервную копию.

Установить обновление типовой конфигурации поставщика.

Выполнить сравнение и объединение, разобрать конфликты.

Применить изменения к базе данных.

Выполнить регрессионное тестирование ключевых сценариев.

Подготовить перенос в рабочую среду.

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

Где чаще всего возникают конфликты

модули объектов и общие модули, если вы правили типовой код;

формы, если вы изменяли типовую форму вместо расширения;

командный интерфейс и роли, если вы «подрезали» типовой интерфейс.

Как уменьшать конфликты заранее

использовать расширения вместо правок типовых объектов;

минимизировать прямые изменения, особенно в «центральных» типовых модулях;

выносить собственную логику в свои общие модули;

не копировать типовой код большими блоками без необходимости.

Совместимость расширений с обновлениями: реальность и риски

Расширение обычно снижает количество конфликтов, но не гарантирует, что обновление пройдет «в один клик».

Типовые причины проблем после обновления типовой:

поставщик изменил форму или реквизит, на который вы опирались;

изменился контракт типового метода, который вы вызываете;

изменился состав или смысл перечислений и предопределенных элементов;

изменились права и роли, и ваша команда/форма стала недоступной.

Промышленная практика: расширение снижает конфликты на этапе слияния, но не отменяет регрессионное тестирование.

Как проектировать доработки, чтобы обновления были предсказуемыми

Ниже набор практик, которые обычно дают максимальный эффект при минимальных усилиях.

Делайте слой собственных сервисов

Создайте общий модуль в расширении для серверной бизнес-логики.

Делайте функции &НаСервереБезКонтекста, если им не нужен UI.

Вызывайте их из форм, объектов и подписок.

Это продолжает принципы из тем про событийную модель и клиент-сервер: форма тонкая, серверные сервисы содержат правила.

Не внедряйте бизнес-логику в печать и отчеты

Печать должна отображать факт, а не «тайно пересчитывать учет».

Отчеты на СКД должны брать корректные данные из регистров.

Это снижает риск, что после обновления «внезапно изменился расчет».

Проектируйте изменения как добавление, а не как ломку

Добавляйте реквизиты и команды, а не переписывайте «ядро» типовых объектов.

Если требуется изменить учетную модель, оцените стоимость отказа от типового и перехода к отдельному решению.

Фиксируйте точки интеграции

Если вы вызываете типовые методы, относитесь к ним как к внешнему контракту:

документируйте, какой типовой метод используется и зачем;

минимизируйте зависимость от внутренних деталей;

оборачивайте вызов в свой сервис, чтобы менять реализацию в одном месте.

Когда расширения недостаточно

Расширение — не универсальная замена архитектуры.

Признаки, что расширения может быть мало:

нужно изменить структуру учета так, что типовые регистры и документы становятся «не теми сущностями»;

требуется массовая перестройка ролей, интерфейса и потоков работы;

доработка затрагивает большинство ключевых объектов типовой.

В таких случаях возможны два промышленных пути:

минимизировать изменения и встроиться в типовой подход;

осознанно принять высокую стоимость сопровождения (глубокие правки типовой) или перейти к отдельному решению.

Итоги

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

Главные практические выводы:

обновляемость — архитектурное свойство проекта, а не «задача админа»;

расширения и внешние обработки обычно дешевле в сопровождении, чем прямые правки типовой;

переопределения должны быть минимальными, точечными и вынесенными в собственный сервисный слой;

обновление — процесс с тестированием, а не одно действие.

Эта тема связывает весь курс в «промышленную рамку»: вы проектируете данные и логику так, чтобы решение можно было безопасно развивать и обновлять годами.

Права доступа и безопасность: роли, RLS, аудит и защита данных

Связь с предыдущими темами курса

Ранее мы разобрали, как устроены метаданные, где живут данные и код, как работает клиент-серверное разделение, проведение документов, запросы и интеграции. Во всех этих темах мы неявно опирались на принцип: система должна быть корректной и устойчивой не только при «правильной работе пользователя», но и при ошибках, злоупотреблениях и внешних воздействиях.

Безопасность в 1С — это не отдельная «галочка», а часть архитектуры:

права определяют, кто может видеть и менять данные;

RLS ограничивает доступ на уровне записей (строк) данных;

аудит фиксирует, кто и что сделал;

защита данных и интеграций обеспечивает устойчивость системы во внешнем мире.

!Многоуровневая модель безопасности: от ролей до аудита

Базовые понятия безопасности в 1С

Идентификация и аутентификация

Идентификация — система понимает, кто пытается войти (логин).

Аутентификация — система проверяет, что это действительно он (пароль, доменная учетная запись и т.д.).

В 1С это реализуется через пользователей информационной базы (и, в зависимости от инфраструктуры, через различные способы входа).

Авторизация

Авторизация — решение, что именно разрешено пользователю после входа. В 1С это зона:

ролей;

прав на объекты;

ограничений доступа к данным (RLS);

прикладных проверок на сервере.

Модель угроз для прикладной логики

Для разработчика важно мыслить практично: откуда реально могут прийти «нежелательные» действия.

Пользователь «обычный» может получить доступ к данным другого подразделения.

Пользователь «продвинутый» может попытаться обойти интерфейсные ограничения.

Интеграция может отправить некорректные данные (намеренно или по ошибке).

Администратор может ошибиться при настройке прав.

Промышленный вывод: нельзя считать безопасность задачей только UI. Критичные ограничения должны обеспечиваться на сервере.

Роли и права: основа авторизации

Что такое роль

Роль — объект метаданных, который описывает набор прав доступа.

Правами обычно управляют на уровнях:

объектных прав (например, читать/записывать справочник, проводить документ);

прав на команды/отчеты/обработки (можно ли выполнять);

прав на данные через RLS (какие строки доступны).

Типовая практика: минимальный набор ролей

Даже в учебной конфигурации полезно закладывать структуру:

Администратор: полный доступ, техническая роль;

Оператор/Менеджер: работа с документами и справочниками своего контура;

Просмотр: только чтение (например, для руководителя или аудитора);

Интеграция (если есть обмен/HTTP): доступ строго к нужным операциям.

Принцип наименьших привилегий

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

Практические последствия:

не выдавайте всем «полные права» ради удобства;

отдельная роль для проведения документов и отдельная для изменения справочников часто снижает риски;

для интеграций почти всегда нужна специализированная роль с ограниченными правами.

Объектные права: что именно настраивается

В конфигурации права задаются для объектов (справочников, документов, регистров, отчетов и т.д.). На практике разработчик должен понимать:

права на справочник влияют на возможность создавать/изменять элементы;

права на документ влияют на создание/запись/проведение;

права на регистр влияют на возможность читать учетные итоги и иногда на запись (в зависимости от архитектуры и механик);

права на отчет/обработку влияют на запуск функциональности.

Промышленный принцип: права должны соответствовать бизнес-процессу. Если пользователь не должен видеть себестоимость, недостаточно «спрятать колонку на форме» — нужно закрывать чтение соответствующих данных и/или строить отчет так, чтобы он не мог вернуть эти значения.

RLS: ограничение доступа к данным на уровне записей

Что такое RLS в 1С

RLS (Row-Level Security) — это ограничение доступа к данным не целиком по объекту, а по конкретным записям.

Примеры задач, которые обычно решают RLS:

менеджер видит только своих клиентов;

сотрудник филиала видит документы только своего подразделения;

пользователь не видит данные «другой организации» в общей базе;

по регистрам видны итоги только по разрешенным складам.

Почему RLS — архитектурно важнее, чем фильтр в форме

Фильтр формы или отбор в динамическом списке — это UI-уровень. Его можно обойти:

открыв данные через другой отчет;

вызвав серверную функцию, если она возвращает данные без ограничений;

используя интеграцию или внешнюю обработку.

RLS же применяется на уровне механизма доступа к данным, поэтому лучше защищает от «случайных обходов».

Как RLS обычно устроен концептуально

RLS в 1С задается как ограничения доступа к данным в рамках роли: условия, при которых строки данных доступны.

Чтобы ограничения работали устойчиво, в модели данных часто требуется явный «разрез доступа», например:

Организация в документах и регистрах;

Подразделение или Склад как реквизит документа и измерение регистра;

Ответственный у контрагентов.

!Как RLS влияет на выборки данных

Практические правила проектирования под RLS

Чтобы RLS не превратился в постоянную боль сопровождения, придерживайтесь правил:

Закладывайте «разрез доступа» в данные заранее.

Делайте разрез доступа единообразным во всех связанных объектах.

Не смешивайте в одной таблице (в одном объекте) данные с разными правилами доступа, если это можно развести по сущностям.

Тестируйте сценарии не только в формах, но и через отчеты/обработки, которые читают те же данные.

Типичные ошибки при внедрении RLS

Условия доступа завязаны на «наименование», а не на ссылку или устойчивый идентификатор.

Ограничение задано для документов, но забыто для регистров: пользователь не видит документ, но видит итоги учета.

Условия доступа используют реквизит, который в части объектов не заполняется — в результате доступ либо «протекает», либо блокируется слишком сильно.

Прикладные проверки безопасности: форма, объект, серверный сервис

Механизмы ролей и RLS — это фундамент, но в промышленной разработке всегда есть слой прикладных правил:

запрет проводить документ, если пользователь не имеет права на проведение именно этого вида операции;

запрет изменять цену ниже минимальной (даже если есть право записи документа);

запрет закрытого периода;

ограничения по лимитам.

Эти правила нельзя оставлять только на форме.

Где размещать проверки

Рекомендуемая схема слоев:

Форма (клиент): подсказки и ранние проверки для удобства.

Модуль объекта (сервер): обязательные проверки перед записью/проведением.

Общий модуль (сервер без контекста): переиспользуемые проверки, которые вызываются из разных объектов.

Привилегированный режим: использовать крайне осторожно

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

Практические правила:

включайте привилегированный режим только там, где это действительно необходимо;

держите «окно привилегий» максимально маленьким по времени и объему кода;

обязательно документируйте причины: какое ограничение обходится и почему это безопасно.

Промышленный риск: если «обернуть» бизнес-логику в привилегированный режим без строгого контроля, можно случайно отключить модель безопасности ролей и RLS.

Аудит: как фиксировать действия пользователей и интеграций

Зачем нужен аудит

Аудит отвечает на вопросы:

кто изменил данные;

когда это произошло;

что именно было сделано;

из какого сценария (пользователь/интеграция/фоновое задание).

Это важно для:

расследования инцидентов;

внутреннего контроля;

поиска причин «почему изменились итоги»;

соответствия требованиям безопасности.

Журнал регистрации платформы

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

Практический подход:

включайте журнал в промышленной среде осознанно (баланс между глубиной аудита и объемом);

заранее договоритесь, какие события критичны (входы, ошибки, изменения прав, проведение документов, интеграционные вызовы);

обеспечьте процедуру хранения и анализа журналов.

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

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Прикладной аудит: когда журнала регистрации недостаточно

Журнал регистрации полезен, но он не всегда отвечает на вопрос «что именно изменилось» в бизнес-смысле.

Типовые решения прикладного аудита:

запись «кто/когда/какой объект/какое действие» в регистр сведений «АудитИзменений»;

хранение идентификатора внешней операции (ExternalRequestId) при интеграциях;

фиксация причин изменения (если бизнес требует).

Промышленная рекомендация: прикладной аудит проектируется вместе с процессом поддержки. Если нет процесса анализа, то аудит превращается в «шумные данные».

Защита данных: конфиденциальность, целостность, доступность

Безопасность данных обычно описывают тройкой:

конфиденциальность: данные видят только те, кому можно;

целостность: данные нельзя незаметно исказить;

доступность: система работает и данные не теряются.

Конфиденциальность: что делать разработчику

не хранить секреты на клиенте;

не возвращать лишние поля из серверных функций и запросов;

в отчетах и печати выводить только то, что разрешено ролями;

использовать RLS и правильные права на объекты.

Целостность: как обеспечивается

обязательные проверки — в модуле объекта и серверных сервисах;

проведение документов должно быть детерминированным и проверять ограничения;

интеграция не должна «писать мимо» бизнес-логики.

Доступность: резервное копирование и эксплуатационные меры

Хотя резервное копирование — зона администрирования, разработчику важно понимать последствия своих решений:

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

неправильные запросы и циклы «запрос на каждую строку» могут перегружать сервер;

отсутствие ограничений в интеграции может привести к лавине запросов.

Безопасность интеграций: HTTP, токены, валидация

Интеграции — частый источник инцидентов, потому что внешняя система:

может быть неверно настроена;

может слать «плохие» данные;

может быть скомпрометирована.

Минимальный промышленный набор требований

защищенный транспорт (HTTPS/TLS);

аутентификация клиента (токен, Basic Auth, сертификаты — по требованиям);

авторизация (отдельная роль интеграции и ограниченные права);

валидация входящих данных на сервере;

идемпотентность операций (повтор запроса не должен ломать учет);

журналирование (запрос, результат, идентификатор операции).

Для общего контекста по практикам веб-безопасности полезен обзор OWASP:

OWASP Top 10

Практический чеклист для разработчика 1С

Ниже список проверок, которые стоит делать перед тем, как считать функциональность «готовой к промышленной эксплуатации».

Роль пользователя не имеет лишних прав «на всякий случай».

Доступ к данным ограничен не только в форме, но и на сервере:

1. через роли и RLS; 2. через проверки в модуле объекта.

Серверные функции возвращают только необходимый минимум данных.

Интеграции используют отдельную роль и отдельный контур прав.

Включен аудит (журнал регистрации и/или прикладной аудит) для критичных операций.

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

Сценарии проверены под пользователем с ограниченными правами, а не только под администратором.

Что дальше по курсу

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

Дальнейшее развитие навыка обычно идет в сторону:

стандартизации «сервисного слоя» серверных модулей, чтобы все проверки и доступ были единообразными;

тестирования (в том числе регресса прав и RLS);

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

Производительность: профилирование, оптимизация запросов и кэширование

Связь с предыдущими темами курса

До этой статьи мы последовательно собрали основу промышленной разработки в 1С:

спроектировали модель данных через справочники, документы и регистры;

научились разделять код по клиенту и серверу и понимать событийную модель;

разобрали запросы 1С и СКД и почему регистры дают быстрые итоги;

научились делать проведение документов так, чтобы учет был целостным;

затронули интеграции и безопасность, где тоже есть производственные требования.

Производительность соединяет все эти темы в один практический принцип: архитектура, данные, запросы, клиент-серверная граница и права доступа всегда проявляются как скорость и устойчивость системы под нагрузкой.

!Цикл работы с производительностью: замер → анализ → исправление → повторный замер

Что такое производительность в 1С и как ее измерять

Производительность в прикладном смысле обычно сводится к трем вопросам.

Сколько времени пользователь ждет результат.

Сколько пользователей система выдерживает одновременно.

Насколько предсказуемо работает система при росте данных.

Чтобы не обсуждать производительность «на ощущениях», в практике закрепляют измеримые метрики.

Время открытия формы.

Время проведения документа.

Время формирования отчета.

Количество клиент-серверных вызовов на сценарий.

Время выполнения ключевых запросов.

Важная привычка промышленной разработки: оптимизация без замера почти всегда приводит к ошибочным выводам.

Профилирование: как найти узкое место, а не «оптимизировать всё подряд»

Профилирование — это процесс, который помогает ответить на вопрос: какая часть сценария реально занимает время.

Типовые источники тормозов в 1С

Чаще всего проблемы лежат в одной (или нескольких) зонах.

Слишком много клиент-серверных переходов из событий формы.

Тяжелые запросы и неправильная модель данных для выборок.

Запросы в цикле по строкам.

Получение «лишних данных» и большие выгрузки в память.

Тяжелые проведения из-за контроля остатков и сложных расчетов.

Влияние RLS на запросы и итоги.

Интеграции, которые запускают тяжелые операции синхронно.

Практический алгоритм профилирования

Чтобы не утонуть в деталях, используйте устойчивый маршрут.

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

Получите базовый замер времени сценария и повторите его несколько раз.

Разделите время по слоям: клиент, сервер 1С, СУБД, сеть.

Выделите топ-3 самых дорогих операций: запросы, циклы, вызовы.

Исправляйте по одной гипотезе и повторяйте замер.

Где обычно смотреть «что было долго»

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

| Уровень | Что диагностируем | Что обычно ищем | |---|---|---| | Клиент | реакция формы, события, частые обработчики | повторяющиеся пересчеты, вызов сервера на каждое изменение поля | | Сервер 1С | выполнение процедур, проведение, формирование отчетов | тяжелые участки кода, многократные обращения к данным | | СУБД | план и стоимость запросов | большие чтения, плохие соединения, отсутствие эффективных индексов | | Сеть | задержки между клиентом и сервером | много мелких вызовов вместо одного пакетного |

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

Производительность клиент-серверного взаимодействия

Эта часть напрямую продолжает темы про управляемые формы и событийную модель.

Почему клиент-серверные вызовы дорогие

Каждый вызов обычно включает:

сериализацию параметров;

сетевую задержку;

выполнение на сервере;

передачу результата обратно.

Даже если сервер выполняет операцию быстро, множество вызовов превращают сценарий в «дерганый».

Типовые антипаттерны

Серверный расчет в обработчике ПриИзменении, который срабатывает многократно при вводе.

Получение данных из базы для каждой строки табличной части отдельным запросом.

Мелкие серверные методы вместо одного метода, который возвращает весь пакет данных.

Типовые исправления

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

Использовать пакетные методы: один серверный вызов получает все нужные данные.

На событиях ввода оставлять только UI-реакции (видимость, доступность, подсказки).

Оптимизация запросов 1С: что дает максимальный эффект

Запросы — самый частый источник нагрузки в промышленных системах, потому что они масштабируются вместе с объемом данных.

Базовые правила, которые почти всегда окупаются

Выбирайте только нужные поля.

Фильтруйте как можно раньше через ГДЕ.

Используйте параметры УстановитьПараметр(), а не конкатенацию строк.

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

Избегайте соединений, которые умножают строки из-за неуникального ключа.

Запрос в цикле — главный враг

Плохая схема:

Хорошая схема:

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

Временные таблицы ПОМЕСТИТЬ: когда они реально помогают

Временные таблицы в запросах полезны, когда:

запрос логически многошаговый;

есть смысл выделить «промежуточный слой» и затем соединять/фильтровать уже его;

нужно избежать повторных вычислений и повторных соединений.

Пример структуры многошагового запроса:

Особенность RLS: запрос может стать тяжелее «сам по себе»

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

Практические следствия:

один и тот же запрос у администратора и у пользователя с RLS может работать по-разному;

тестировать производительность нужно под «боевыми» ролями, а не только под полными правами;

кэширование результатов становится сложнее, потому что результат зависит от пользователя и его прав.

Кэширование: когда нужно и как делать безопасно

Кэширование — это сохранение результата вычисления или выборки, чтобы не делать одно и то же повторно.

Когда кэширование оправдано

Кэширование обычно оправдано, если одновременно выполняются условия.

Данные меняются редко, а читаются часто.

Расчет или запрос дорогой.

Результат можно однозначно определить по параметрам.

Есть понятный способ сбросить кэш при изменении исходных данных.

Примеры сущностей, которые часто подходят для кэша:

настройки пользователя;

справочные данные, которые редко меняются;

«актуальные цены на дату» для подбора, если они не меняются каждую секунду;

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

Уровни кэширования в прикладной разработке

В 1С удобно мыслить слоями: где хранится кэш и каков его жизненный цикл.

| Уровень кэша | Жизненный цикл | Пример применения | Главный риск | |---|---|---|---| | Локальный в процедуре | один серверный вызов | не повторять один и тот же запрос дважды в одной операции | почти нет, если контролировать память | | Кэш формы | пока форма открыта | результаты подбора, временные таблицы значений | устаревание данных при долгой работе | | Кэш в сеансе | пока пользователь в системе | настройки, предрасчитанные справочные соответствия | смешивание данных разных прав и ролей | | Долгоживущий кэш в базе | хранится как данные | кеш-таблицы, регистры сведений для предрасчетов | усложнение поддержки и актуализации |

!Слои кэша: что можно хранить на форме, в сеансе и что остается в базе

Базовый шаблон кэширования в серверном сервисе

Идея: сделать серверную функцию, которая возвращает данные, и хранить результат в соответствии по ключу параметров.

Что важно понимать промышленно:

такой кэш нужно сбрасывать при изменениях данных или хотя бы ограничивать по времени;

кэш не должен нарушать безопасность, поэтому ключ часто должен включать пользователя или контур доступа;

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

Стратегии инвалидции кэша

Кэш не имеет смысла, если вы не понимаете, когда он становится неверным.

Инвалидция по времени: кэш живет, например, 60 секунд.

Инвалидция по событию: при записи цены или приходе товара кэш по соответствующим ключам сбрасывается.

Инвалидция по контексту: кэш действует только внутри одной операции (самый безопасный вариант).

Практический вывод: чем проще инвалидция, тем надежнее кэш.

Кэширование и безопасность

Кэширование особенно опасно в двух сценариях.

Результат зависит от RLS или ролей, а вы кэшируете «на всех».

Вы кэшируете на клиенте данные, которые не должны быть доступны пользователю.

Правило: если результат может отличаться для разных пользователей, кэш должен быть как минимум «персональным» или «по контуру доступа».

Типовые ошибки производительности и быстрые способы лечения

Ошибка: «форма тормозит при вводе»

Частый источник: серверные вызовы в ПриИзменении.

Исправление:

перенести расчет на команду;

делать один серверный вызов вместо нескольких;

использовать ПриОкончанииВвода там, где это уместно.

Ошибка: «проведение стало медленным на больших документах»

Частый источник: запросы в цикле и контроль остатков по каждой строке.

Исправление:

один пакетный запрос остатков;

сравнение «потребность против остатка» в памяти;

минимум обращений к базе.

Ошибка: «отчет стал медленным после внедрения RLS»

Частый источник: запросы были «на грани» и после добавления ограничений стали тяжелыми.

Исправление:

пересмотреть источник данных (регистры вместо документов);

уменьшить поля и строки выборки;

проверить соединения и группировки;

тестировать под реальными ролями.

Мини-чеклист промышленной работы с производительностью

Замерили время сценария и повторили замер после изменения.

Проверили количество клиент-серверных вызовов.

Убрали запросы в цикле, заменили на пакетные выборки.

Используем параметры запросов, а не конкатенацию.

Для учета используем регистры и виртуальные таблицы.

Понимаем, где и как инвалидируется кэш.

Протестировали сценарий под пользователем с ограниченными правами и RLS.

Что дальше по курсу

Производительность — это мост к промышленной эксплуатации и командной разработке.

Дальше в практике обычно идут темы, которые закрепляют производственный контур:

стандарты разработки и архитектурная дисциплина в команде;

регламент обновлений и регресс производительности;

эксплуатационные аспекты: мониторинг, анализ инцидентов, нагрузочные проверки.

Всё это опирается на фундамент из курса: правильная модель данных, корректное проведение, быстрые запросы, разумное клиент-серверное разделение и безопасная работа с правами.

Хранилище конфигурации, Git, EDT и командная разработка

Как эта тема связана с предыдущими статьями курса

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

Командная разработка в 1С — это ответ на практические вопросы:

как параллельно разрабатывать одну конфигурацию нескольким разработчикам;

как хранить историю изменений и быстро находить, кто и что поменял;

как делать код-ревью и управлять качеством;

как обновлять типовые и поддерживать расширения без хаоса;

как обеспечить воспроизводимость: одинаковый результат на разных машинах.

В 1С наиболее распространены два семейства подходов:

хранилище конфигурации 1С как встроенный централизованный механизм;

Git как индустриальный стандарт VCS вместе с EDT как средой разработки, ориентированной на работу с исходниками.

!Общая карта командного процесса: от разработки до релиза

Зачем вообще нужен контроль версий

Система контроля версий — это инструмент, который хранит историю изменения исходников и помогает нескольким людям параллельно менять один продукт.

Что дает контроль версий в промышленной работе:

история: можно посмотреть, что изменилось и почему;

откат: можно вернуться к рабочему состоянию;

параллельность: разные разработчики делают разные задачи одновременно;

согласование: код-ревью и правила внесения изменений;

воспроизводимость: из репозитория можно восстановить состояние проекта.

Важно: для 1С контроль версий — это не только про код модулей. Это еще и про метаданные (справочники, документы, формы, роли, регистры), которые должны храниться и развиваться контролируемо.

Хранилище конфигурации 1С

Что это такое

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

Ключевая идея хранилища:

изменения фиксируются как версии в хранилище;

разработчики получают объекты из хранилища, изменяют их и помещают обратно;

часто используется модель блокировок на объекты, чтобы два человека не меняли один и тот же объект одновременно.

Базовые термины хранилища

Версия — состояние конфигурации в хранилище в определенный момент.

Получить из хранилища — забрать актуальную версию (или отдельные объекты) к себе.

Поместить в хранилище — отправить свои изменения в централизованное хранилище.

Захват (блокировка) объекта — защита от параллельного изменения одного и того же объекта.

Типичный рабочий цикл

Разработчик получает свежую версию конфигурации из хранилища.

Захватывает нужные объекты (документ, форму, общий модуль).

Вносит изменения в конфигураторе.

Помещает изменения в хранилище с комментарием.

Остальные разработчики обновляются.

Плюсы и минусы хранилища

| Критерий | Хранилище 1С | Что это означает на практике | |---|---|---| | Встроенность | Высокая | работает «из коробки» в экосистеме 1С | | Модель параллельной работы | Обычно через блокировки | снижает число конфликтов, но ограничивает параллельность | | История изменений | Есть | но обычно менее удобна для код-ревью и автоматизации, чем Git | | Интеграция с CI/CD | Ограниченная | можно построить, но чаще сложнее и менее стандартно | | Работа с ветками | Не основной сценарий | ветвление и сложные стратегии разработки обычно реализуются хуже |

Когда хранилище оправдано

Хранилище часто выбирают, когда:

команда привыкла к конфигуратору как к основной среде;

проект исторически живет в хранилище;

важна модель блокировок как организационный механизм;

нет зрелого процесса Git и инфраструктуры вокруг него.

Git как основа промышленной командной разработки

Что такое Git

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

Ключевые понятия Git:

репозиторий — папка проекта вместе с историей изменений;

коммит — зафиксированное изменение с автором, временем и комментарием;

ветка — параллельная линия разработки;

слияние (merge) — объединение изменений из веток;

pull request / merge request — процесс ревью и согласованного вливания изменений (зависит от платформы: GitLab, GitHub и другие).

Официальная документация Git:

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

Почему Git — промышленный стандарт

Git хорош для командной разработки, потому что:

поддерживает ветвление как норму, а не как исключение;

позволяет строить процесс через ревью;

легко подключается к CI/CD;

имеет огромную экосистему инструментов.

Но есть важная особенность 1С:

конфигурация в базе — это не «набор файлов» в привычном смысле;

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

Зачем нужен EDT в связке с Git

Что такое EDT

1C:Enterprise Development Tools (EDT) — среда разработки 1С, ориентированная на командную работу и хранение конфигурации в виде исходников в файловой структуре проекта.

Официальная страница EDT:

1C:Enterprise Development Tools

Чем EDT отличается от конфигуратора в контексте команды

EDT удобен для Git-подхода, потому что:

работает с проектом в файловом виде, а значит изменения можно фиксировать в Git;

поддерживает типичный для индустрии цикл: ветки, ревью, автоматические проверки;

позволяет разработчикам параллельно менять разные части проекта без «центральной блокировки» как основного механизма.

Что такое «исходники конфигурации» в Git-подходе

В Git-подходе команда хранит в репозитории:

модули (BSL) в текстовом виде;

описания объектов метаданных в файловом представлении проекта;

файлы расширений, общие модули, макеты в виде, пригодном для сравнения.

Практический смысл:

Git видит разницу построчно;

можно делать ревью изменений;

можно выполнять автоматические проверки качества кода.

Сравнение подходов: хранилище 1С и Git+EDT

| Вопрос | Хранилище конфигурации 1С | Git + EDT | |---|---|---| | Как обеспечивается параллельная работа | через захват объектов | через ветки и слияния | | Как делается ревью | обычно вне инструмента или ограниченно | как стандартный процесс (pull request) | | Как решаются конфликты | чаще предотвращаются блокировками | решаются через merge, требуется дисциплина | | Насколько просто автоматизировать проверки | ограниченно | обычно проще: CI, линтеры, автотесты | | Кто обычно выбирает | команды «конфигуратор-first» | команды с практиками промышленной разработки |

Важно: на практике встречаются гибриды, но стратегию лучше выбирать осознанно и закреплять регламентом.

Как организовать командную разработку на Git: минимальный рабочий регламент

Ниже — компактный набор правил, который дает промышленный эффект даже в небольшой команде.

Структура работы через ветки

Два популярных подхода:

trunk-based development: короткоживущие ветки задач, частое вливание в основную ветку.

GitFlow: несколько долгоживущих веток (например, main, develop, release).

Для большинства 1С-команд, которые только выстраивают процесс, проще начать с trunk-based:

Есть основная ветка (например, main).

На задачу создается ветка feature/<номерЗадачи>.

Разработка ведется в ветке, изменения фиксируются небольшими коммитами.

Создается pull request, проходит ревью.

После вливания запускаются проверки и сборка.

Правила хороших коммитов

Коммит — это единица истории. Чем лучше история, тем проще сопровождать.

Практические правила:

один коммит — одна логическая причина изменения;

комментарий коммита должен объяснять зачем, а не только что;

избегайте гигантских коммитов «сразу всё».

Примеры читаемых сообщений:

Исправлен контроль отрицательных остатков при проведении реализации

Добавлен отчет ПродажиПоКлиентам на СКД

Код-ревью как обязательная точка контроля

Код-ревью в 1С особенно полезно, потому что помогает ловить:

нарушения клиент-серверного разделения;

запросы в цикле и другие проблемы производительности;

ошибки в проведении и целостности учета;

нарушения правил безопасности и доступа.

Минимальный промышленный стандарт:

любая задача вливается через pull request;

есть хотя бы один reviewer;

замечания фиксируются письменно.

Конфликты и как их минимизировать в 1С-проектах

Почему конфликты в 1С могут быть сложнее

В 1С много изменений относится к метаданным и формам, а не только к текстовому коду. Поэтому конфликты возникают не только «строка к строке», но и на уровне структуры объекта.

Практики снижения конфликтов

Дробите задачи так, чтобы два разработчика не правили один и тот же объект.

Избегайте параллельных изменений одной и той же формы.

Выносите переиспользуемую логику в общие модули, чтобы меньше трогать «центральные» объекты.

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

Используйте расширения там, где это уместно, чтобы не «биться» за типовые объекты.

Эти правила напрямую связаны с темами курса про архитектуру, расширения и производительность: чем чище разделение ответственности, тем меньше конфликтов.

Среда разработки команды: что должно быть стандартизировано

Чтобы команда получала одинаковый результат, важно закрепить базовые стандарты.

Версии платформы и инструментов

Нужно договориться и зафиксировать:

версия платформы 1С;

версия EDT;

правила обновления версий.

Если это не закрепить, команда получит «необъяснимые расхождения»: у одного разработчика форма ведет себя иначе, у другого запрос компилируется по-другому.

Единые правила стиля и качества

В промышленной команде обычно определяют:

правила именования объектов и модулей;

требования к директивам контекста &НаКлиенте, &НаСервере, &НаСервереБезКонтекста;

минимальные проверки производительности (например, запрет запросов в цикле);

правила работы с правами и запрет «всё в привилегированном режиме».

Связь с CI/CD: почему командная разработка не заканчивается Git

Даже если статья не про CI/CD, важно понимать связку.

Git-процесс становится промышленным, когда после вливания:

запускаются автоматические проверки (качество кода, сборка, тесты);

формируется артефакт поставки;

изменения попадают в тестовую среду предсказуемым способом.

Это продолжает идеи из темы про производительность: проверять нужно не «когда стало плохо», а на каждом шаге.

Практический чеклист: готовность проекта 1С к командной разработке

Определен основной подход: хранилище 1С или Git+EDT.

Зафиксированы версии платформы и инструментов.

Есть регламент веток и pull request.

Есть минимальные правила оформления коммитов.

Есть договоренность, как минимизировать конфликты по объектам.

Критичная логика не живет в формах, а находится на сервере и в объектах.

Разработка и обновления типовых делаются через расширения там, где это возможно.

Что дальше

После этой темы логично перейти от инструментария команды к процессу поставки:

как собирать релизы и поддерживать несколько контуров (разработка, тест, продуктив);

как организовать регрессионное тестирование и контроль качества;

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

Тестирование и качество: сценарии, TDD-подходы и статический анализ

Связь с предыдущими темами курса

До этой статьи мы разобрали, как проектировать данные и учет (справочники, документы, регистры), как писать код с учетом событийной модели и клиент-серверного разделения, как строить запросы и отчеты, как делать интеграции, обеспечивать безопасность и производительность. Последняя изученная тема — командная разработка (хранилище, Git, EDT).

Эта статья добавляет контур качества: как сделать так, чтобы функциональность:

работала одинаково на разных данных и у разных пользователей;

не ломалась при обновлениях, изменениях и параллельной разработке;

была проверяемой автоматически, а не только ручной проверкой «открыли форму — вроде работает».

!Пирамида тестирования помогает выбрать правильный уровень проверки

Что такое качество в 1С-проектах

Под качеством в промышленной разработке обычно понимают сочетание нескольких свойств.

Корректность: учетные итоги и правила выполняются всегда.

Регрессионная устойчивость: новое изменение не ломает старые сценарии.

Предсказуемость: одинаковые входные данные дают одинаковый результат.

Сопровождаемость: код и метаданные можно менять без «минного поля».

В 1С качество особенно зависит от архитектурных решений из предыдущих тем:

если бизнес-правила живут в форме, их легко обойти (обработка, обмен, внешняя интеграция);

если запросы выполняются в цикле, тесты могут проходить на маленьких данных и «умирать» на больших;

если нет контроля версий и ревью, ошибки попадают в релиз незаметно.

Тестовые сценарии: как формулировать то, что нужно проверять

Тестирование начинается не с инструмента, а с сценариев — формализованных ожиданий.

Сценарий как контракт

Сценарий полезно формулировать в структуре Дано–Когда–Тогда (это общий принцип BDD: behavior-driven development, разработка через поведение).

Дано: состояние системы и данные (справочники заполнены, есть остаток, у пользователя есть роль).

Когда: действие (создали документ, провели, выполнили отчет, вызвали HTTP-метод).

Тогда: ожидаемый результат (движения по регистрам, остатки, ошибки, запрет доступа).

Пример (уровень смысла, не инструмент):

Дано: на складе Склад-1 есть 10 единиц Товар А.

Когда: проводим реализацию на 12 единиц.

Тогда: проведение должно быть запрещено с понятным сообщением о нехватке.

Какие сценарии критичны в 1С

В промышленном учете чаще всего «болят» следующие зоны:

проведение документов и движения по регистрам;

расчеты цен, скидок, налогов, округлений;

отчеты, которые используют виртуальные таблицы регистров;

права доступа и RLS (пользователь не должен увидеть лишнее);

интеграции (повторы, идемпотентность, валидация входных данных).

Практическое правило: сначала покрывайте тестами сценарии, где ошибка стоит дорого (учет, деньги, безопасность), а потом — удобство интерфейса.

Уровни тестирования в 1С: что именно тестировать

Модульные тесты (unit tests)

Модульный тест проверяет маленькую единицу логики (обычно функцию) без сложного окружения.

В 1С лучше всего подходят для модульного тестирования:

серверные функции &НаСервереБезКонтекста в общих модулях;

чистые расчеты (сумма, скидка, правило округления);

преобразования данных (структуры, таблицы значений), маппинг интеграции.

Почему это работает: чем меньше зависимостей (форма, база, права, регистры), тем дешевле тест.

Инструменты (как примеры экосистемы):

xUnitFor1C

Интеграционные тесты

Интеграционный тест проверяет взаимодействие нескольких компонентов.

В 1С это часто:

запись и проведение документа;

движения по регистрам и контроль остатков;

запросы к виртуальным таблицам регистров;

проверка RLS и ролей на чтение данных;

обработка входящего пакета обмена.

Особенность интеграционных тестов: они требуют тестовых данных и изоляции (отдельная тестовая база или отдельный контур).

UI/приемочные тесты

UI-тесты (или приемочные) проверяют сценарий так, как его делает пользователь: открыть форму, ввести данные, нажать команды.

Это полезно, но дороже всего:

они медленнее;

их сложнее поддерживать при изменениях форм;

они чувствительны к окружению.

Инструменты (как примеры):

Vanessa Automation

Практическое правило: UI-тесты держите для ключевых цепочек (например, «создать документ → провести → распечатать»), а детали логики старайтесь тестировать ниже уровнем.

Тестируемость как следствие архитектуры

Чтобы тестирование было реальным, а не «для галочки», код нужно писать так, чтобы его можно было проверить.

Принципы тестируемого кода в 1С

Тонкая форма: форма запускает команды и показывает результат, а бизнес-логика — на сервере.

Сервисы без контекста: функции &НаСервереБезКонтекста проще вызывать из тестов.

Минимум глобального состояния: модульные переменные и кэш усложняют воспроизводимость.

Явные параметры вместо чтения “из воздуха”: передавайте дату, организацию, склад параметрами.

Если в проекте соблюдены принципы из тем про клиент-сервер и архитектуру модулей, то модульные и интеграционные тесты пишутся существенно проще.

TDD в 1С: как применять подход практически

TDD (test-driven development) — подход, при котором разработка идет циклом:

написать тест, который описывает ожидаемое поведение, и убедиться, что он падает;

написать минимальный код, чтобы тест прошел;

улучшить код (рефакторинг), сохранив прохождение теста.

Важно: TDD — это не «везде писать тесты», а способ проектировать контракт функций и сервисов.

Где TDD особенно хорошо ложится в 1С

расчеты (скидки, лимиты, округления);

правила валидации данных (например, формат номера, заполненность);

преобразование форматов интеграции (JSON/XML → структура → объект);

сервисы получения данных (например, «получить актуальную цену на дату») при условии, что вы отделили запрос от логики принятия решения.

Типовой пример TDD-мышления

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

Формулируете контракт: РассчитатьСкидку(Сумма, Контрагент) -> ПроцентСкидки.

Пишете тесты на крайние случаи:

- пустой контрагент → 0; - сумма меньше порога → 0; - сумма больше порога → 10.

Реализуете функцию.

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

Статический анализ: как ловить проблемы до запуска

Статический анализ — это проверка кода без выполнения: стиль, потенциальные ошибки, архитектурные нарушения.

В 1С он особенно полезен, потому что часть дефектов типовая:

забыли директиву контекста (&НаКлиенте/&НаСервере);

попытались выполнить серверную операцию на клиенте;

запросы в цикле;

неиспользуемые переменные и параметры;

потенциально опасные конструкции (например, невалидированные входные данные интеграции).

Что обычно проверяют статическим анализом в 1С

корректность синтаксиса и компиляции модулей;

соответствие правилам оформления и стандартам команды;

потенциальные ошибки времени выполнения;

архитектурные правила (например, запрет тяжелых запросов из обработчиков ПриИзменении).

Инструменты статического анализа для BSL

Один из распространенных инструментов экосистемы:

BSL Language Server

Практическая ценность: статический анализ хорошо включается в командный процесс (Git-пайплайн или локальные проверки) и снижает количество дефектов, которые «долетели» до тестировщика или пользователя.

Как встроить качество в командную разработку

Связка с прошлой темой (Git/EDT) выглядит так: качество должно быть частью процесса внесения изменений.

!Quality gates показывают, где останавливать плохие изменения до релиза

Минимальный промышленный регламент качества

Изменения попадают в основную ветку только через pull request.

В pull request обязательно:

- статический анализ; - минимальный набор автоматических тестов.

Для рисковых изменений (проведение, RLS, интеграции) добавляется регрессионный сценарий.

Ревьюер проверяет не только “работает”, но и архитектуру:

- нет ли бизнес-логики в форме; - нет ли запросов в цикле; - нет ли обхода прав и RLS; - соблюдены ли контексты выполнения.

Тестовые данные: почему без них тесты “не взлетают”

Автотесты в 1С часто ломаются не из-за логики, а из-за данных.

Принципы хороших тестовых данных

Минимальность: создавайте ровно то, что нужно сценарию.

Изоляция: тест не должен зависеть от “случайно уже введенных” справочников.

Повторяемость: тест можно выполнить на пустой базе и получить тот же результат.

Ясные имена: тестовые объекты должны читаться как роль в сценарии (например, ТоварТест, СкладТест).

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

Типичные дефекты и какие проверки ловят их дешевле

| Дефект | Почему опасно | Дешевле всего ловить | Примечание для 1С | |---|---|---|---| | Бизнес-правило только на форме | можно обойти через обработку/обмен | интеграционный тест проведения + ревью | правило должно быть в объекте/сервисе | | Запрос в цикле | деградация на объеме данных | статический анализ + ревью | дальше проявится как “тормозит” | | Ошибка RLS | утечка данных | интеграционные тесты под ролью | проверяйте не только формы, но и отчеты | | Нестабильная печать | первичка “поехала” | сценарный тест + сверка шаблона | печать не должна пересчитывать учет | | Неидемпотентная интеграция | повторы создают дубли | интеграционный тест повтора | храните идентификатор операции |

Практический чеклист “готово качественно”

Критичные правила продублированы на сервере (модуль объекта/сервис), а не только на форме.

Есть автоматическая проверка хотя бы на один ключевой сценарий изменения.

Запросы параметризованы и нет запросов в цикле.

Проверено под ролью с реальными ограничениями (включая RLS, если используется).

Включен статический анализ в локальном запуске или пайплайне.

Изменение проходит через pull request и ревью.

Что дальше по курсу

Эта статья завершает базовый промышленный контур разработки практиками качества.

Дальше логичное развитие курса обычно идет в сторону поставки и эксплуатации:

как организовать контуры (dev/test/prod) и релизный процесс;

как автоматизировать проверки (CI) и сборку;

как измерять качество на истории релизов (регресс, инциденты, производительность).

Тесты, TDD-мышление и статический анализ — это инструменты, которые позволяют развивать 1С-систему годами без потери управляемости.

Администрирование и выпуск: публикация, кластеры, фоновые задания и мониторинг

Связь с предыдущими темами курса

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

Эта тема добавляет эксплуатационный слой промышленной разработки: как сделать так, чтобы ваше решение:

стабильно работало в многопользовательской среде;

корректно публиковалось для пользователей (тонкий клиент и веб);

выдерживало регламентные операции и фоновые обработки;

было наблюдаемым (можно понять, что происходит, и почему “тормозит”);

выпускалось в релизы предсказуемо и с минимальным риском.

Полезные точки входа в официальные материалы по технологии платформы:

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

!Общее представление, какие компоненты участвуют в публикации, выполнении фоновых задач и наблюдаемости

Контуры среды: dev, test, prod как основа администрирования

В промышленной разработке важно не только что вы сделали, но и где это работает.

Типовой набор контуров:

Dev: разработка и быстрые проверки.

Test: регрессия, проверка прав, производительности, интеграций.

Prod: рабочая среда.

Ключевая мысль для разработчика: часть проблем видна только на “похожей на прод” инфраструктуре.

поведение фоновых заданий и регламентных операций в файловой базе и в кластере отличается;

производительность запросов и влияние RLS в одиночной базе и при нагрузке отличаются;

интеграции (HTTP/обмены) в “локалке” часто работают иначе, чем через реальный контур сети и прокси.

Публикация: как пользователи подключаются к вашей системе

Публикация в 1С обычно означает организацию доступа пользователей к информационной базе.

Основные варианты доступа

| Вариант | Как подключаются пользователи | Типичная область применения | Главный риск/ограничение | |---|---|---|---| | Файловая база | напрямую к каталогу базы | обучение, малые установки | слабая масштабируемость, риски при многопользовательской работе | | Клиент-сервер | тонкий клиент → сервер 1С → СУБД | промышленная эксплуатация | требуется настройка сервера 1С и СУБД | | Веб-клиент | браузер → веб-сервер → сервер 1С → СУБД | удаленный доступ, “ничего не ставить” | ограничения веб-клиента, требования к публикации на веб-сервере |

Практический вывод: промышленная эксплуатация почти всегда опирается на клиент-сервер и, часто, на веб-публикацию.

Публикация веб-клиента и HTTP-сервисов: что важно понимать

Веб-доступ и входящие HTTP-интеграции обычно требуют веб-сервера.

На практике чаще встречаются:

Microsoft IIS

Apache HTTP Server

Что важно как разработчику (не углубляясь в системное администрирование):

веб-клиент и HTTP-сервисы живут в “веб-контуре”, и ошибки там часто связаны не с вашим кодом, а с маршрутизацией, сертификатами, правами, заголовками и ограничениями окружения;

код должен учитывать отличие окружения: то, что работает в тонком клиенте, может требовать другого подхода в веб-клиенте;

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

Публикация и безопасность: зона ответственности разработчика

Публикация сама по себе не делает систему безопасной.

Минимальные правила, которые должен удерживать разработчик:

не полагаться на скрытие кнопок: серверные проверки обязаны быть в модулях объектов и серверных сервисах;

разделять пользователей и роли: отдельные роли для интеграций, ограниченные права и RLS там, где требуется;

логировать критичные операции: хотя бы на уровне журнала регистрации и прикладного аудита для важных действий.

Кластер серверов 1С: зачем он нужен и как он устроен

Кластер серверов 1С нужен, чтобы обеспечить многопользовательскую работу, распределение нагрузки и управляемость.

Термины кластера, которые нужно знать разработчику

| Термин | Смысл | Почему важно разработчику | |---|---|---| | Кластер | логическая группа серверов 1С | влияет на масштабирование и отказоустойчивость | | Рабочий процесс | процесс, в котором выполняется серверный код и обслуживаются сессии | тяжелые операции и утечки памяти проявляются здесь | | Сессия | подключение пользователя/интеграции | влияет на нагрузку, блокировки, конкуренцию | | Фоновые задания | выполнение кода без UI, обычно по расписанию или очереди | нужно писать код так, чтобы он был устойчивым и наблюдаемым |

Что меняется в логике разработки, когда появляется кластер

В кластерной среде “неочевидные” вещи становятся критичными.

любой лишний клиент-серверный вызов масштабируется на число пользователей;

запрос “в цикле” превращается в массовую нагрузку на СУБД;

неконтролируемые исключения в фоне приводят к лавине ошибок и повторов;

кэширование “на модульных переменных” может стать источником нестабильности, если вы не понимаете жизненный цикл процессов.

Балансировка и отказоустойчивость: практическая картина

Кластер обычно стремится:

распределять сессии между рабочими процессами;

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

выполнять фоновые задания на серверной стороне.

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

если операция может быть выполнена дважды, вы должны либо сделать ее идемпотентной, либо вести учет выполненных операций;

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

!Упрощенная модель кластера, чтобы понимать, где реально исполняется ваш код

Фоновые задания и регламентные операции: как делать правильно

Фоновые задачи в 1С нужны для всего, что не должно выполняться в UI-сценарии:

обмены и интеграции по расписанию;

загрузки данных;

пересчеты итогов, подготовка витрин;

рассылки уведомлений;

длительные обработки.

Чем фоновое выполнение отличается от “нажали кнопку на форме”

Ключевые отличия:

нет пользователя, который “дождется” или “поймет ошибку”;

выполнение может быть прервано перезапуском процесса или узла;

типичны повторы и необходимость возобновления;

критичны журналирование, устойчивость и ограничение ресурсов.

Правила промышленного фонового кода

Только сервер

- фоновый код должен быть серверным и не зависеть от формы; - предпочтительно &НаСервереБезКонтекста для сервисной логики.

Идемпотентность

- повторный запуск не должен приводить к дублям документов, повторному списанию или “разъезду учета”; - если внешняя система прислала повтор, это должно обрабатываться как “уже сделано”.

Наблюдаемость

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

Пакетность вместо циклов запросов

- собирайте ключи и делайте один запрос; - избегайте “для каждой строки отдельный запрос”.

Ограничение времени и объема

- большие операции делите на порции; - храните прогресс (например, “последний обработанный идентификатор/период”).

Типовая архитектура фоновой операции

Удобная схема, которая хорошо сочетается с темами про интеграции, производительность и качество:

общий модуль СервисФона &НаСервереБезКонтекста:

- получить порцию задач; - обработать порцию; - зафиксировать статус;

регистр сведений ЖурналФоновыхОпераций:

- идентификатор операции; - статус; - время начала/окончания; - текст ошибки;

UI-форма (опционально):

- показать состояние и историю; - запустить вручную.

Важная дисциплина: фоновые операции не должны “прятать” бизнес-логику. Если фоновая задача создает документы, эти документы должны проходить те же проверки записи и проведения.

Мониторинг: как понимать, что происходит в системе

Мониторинг в 1С нужен, чтобы отвечать на практические вопросы:

почему “тормозит” открытие формы или проведение;

что сейчас нагружает сервер;

почему не отработали фоновые задания;

почему интеграция дает ошибки;

где искать причину инцидента.

Слои мониторинга: от приложения до СУБД

| Слой | Что наблюдаем | Типовые симптомы проблем | |---|---|---| | Клиент | время реакции UI, частые действия, ошибки на форме | “подвисает при вводе”, “долго открывается список” | | Сервер 1С | выполнение процедур, проведение, фоновые задания, сессии | “проведение стало в 5 раз дольше”, “очередь фоновых растет” | | СУБД | планы и стоимость запросов, блокировки, нагрузка | “запросы стали тяжелыми”, “блокировки”, “рост времени ответа” | | Инфраструктура | сеть, CPU/RAM, диск, веб-сервер | “все медленно”, “ошибки таймаута”, “падает веб” |

Для разработчика главная мысль: диагностика почти всегда начинается с вопроса в каком слое проблема.

Журналирование: что важно фиксировать на уровне приложения

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

Что особенно важно логировать:

ошибки проведения и отказ в проведении с контекстом (какой документ, какая номенклатура, какое ограничение);

ошибки интеграций и входящих HTTP-вызовов (идентификатор запроса, статус, причина);

результаты фоновых задач (сколько обработано, за сколько времени, какие ошибки).

Практический принцип: лог должен отвечать на вопрос что делать дальше, а не только “произошла ошибка”.

Метрики производительности, которые полезны разработчику

Не обязательно сразу строить сложный APM, но полезно договориться о базовых измерениях:

среднее/максимальное время проведения ключевых документов;

время формирования ключевых отчетов;

количество ошибок интеграции в сутки;

размер очередей фоновых заданий;

наличие длительных блокировок в СУБД.

Смысл этих метрик напрямую связан с темами курса про производительность и качество: вы не “угадываете”, а видите деградацию по цифрам.

!Карта, откуда брать данные для расследования проблем

Выпуск изменений: как разработка превращается в релиз

Выпуск в 1С — это не только “залить конфигурацию”. Это управляемая последовательность действий, где важны безопасность, повторяемость и возможность отката.

Из чего состоит поставка

В зависимости от проекта в релиз могут входить:

изменения конфигурации или расширения;

обновление конфигурации базы данных;

миграции данных (обработки заполнения, переносы, пересчеты);

изменения прав/ролей;

изменения интеграций и настроек публикации;

обновление платформы (отдельный контур, но влияющий на поведение).

Почему релиз опасно делать “вручную по памяти”

Типовые риски:

забыли применить изменение структуры и “на проде не появилось поле”;

обновили расширение, но не проверили права и команды стали недоступны;

выпустили изменение, которое ломает фоновую задачу, и очередь начала расти;

не проверили под ролью с RLS, и отчет стал работать медленно.

Поэтому промышленный подход всегда опирается на регламент и чеклисты.

Минимальный промышленный регламент релиза

Подготовка

- фиксация состава изменений; - проверка, что изменения в Git/хранилище соответствуют задаче; - наличие инструкции по обновлению (что, где, в каком порядке).

Прогон в тестовом контуре

- автоматические проверки (статический анализ, тесты); - регресс ключевых сценариев: проведение, отчеты, печать, интеграции; - проверка прав и RLS на реальных ролях.

Резервное копирование

- до обновления в рабочем контуре должна быть понятная точка возврата.

Выпуск

- обновление конфигурации/расширения; - применение изменений к базе данных; - запуск обработок заполнения и регламентных операций, если требуется.

Постконтроль

- проверка критичных метрик и журналов ошибок; - контроль фоновых заданий; - контроль интеграций.

!Упрощенный пайплайн выпуска изменений в промышленной 1С

Практические ошибки на стыке разработки и администрирования

Ниже список ошибок, которые чаще всего “вылезают” уже после публикации, и как их предотвращать архитектурно.

Бизнес-логика в форме

Последствия:

интеграция или фоновая обработка обходит правила;

в веб-клиенте часть поведения отличается;

при нагрузке растет число клиент-серверных вызовов.

Профилактика:

серверные сервисы &НаСервереБезКонтекста;

проверки в модуле объекта и проведении.

Запросы в цикле и мелкие серверные вызовы

Последствия:

на объеме данных и количестве пользователей система деградирует;

“в тесте работало, в проде тормозит”.

Профилактика:

пакетные запросы;

один серверный метод на операцию;

измерение времени и профилирование сценариев.

Фоновая операция без контроля повтора

Последствия:

дубли документов;

повторные списания;

рассинхронизация интеграций.

Профилактика:

идентификаторы операций;

журнал обработки;

идемпотентность.

Отсутствие наблюдаемости

Последствия:

инциденты “не расследуются”, их только “перезапускают”;

регресс производительности замечают слишком поздно.

Профилактика:

прикладное журналирование;

понятные сообщения об ошибках;

базовые метрики и контроль после релиза.

Итоги

Администрирование и выпуск в 1С — это продолжение разработки, а не отдельная “чужая область”. Промышленный разработчик должен уметь проектировать решение так, чтобы оно:

корректно публиковалось и работало в клиент-серверной среде;

было устойчивым в кластере и под нагрузкой;

выполняло фоновые задачи предсказуемо и безопасно;

было наблюдаемым через логи и метрики;

выпускалось в релизы по повторяемому регламенту.

Это замыкает курс в промышленную картину: архитектура и код → эксплуатация и выпуск → контроль качества и стабильности.

Практический проект: разработка подсистемы от ТЗ до релиза

Зачем нужна эта тема и как она связывает весь курс

В предыдущих темах курса мы изучали отдельные «кирпичи» промышленной разработки 1С:

метаданные и модель данных (справочники, документы, регистры)

встроенный язык, модули и клиент-серверное разделение

управляемые формы, события и навигацию

запросы, СКД, отчеты и печатные формы

проведение документов и контроль учета

обмены и интеграции

расширения и обновления типовых

права, RLS и аудит

производительность

командную разработку (хранилище, Git, EDT)

тестирование и качество

выпуск и эксплуатацию (публикация, фоновые задания, мониторинг)

Эта статья собирает всё в один практический маршрут: как разработать подсистему от постановки (ТЗ) до релиза, так, чтобы результат был:

архитектурно чистым (логика в правильных слоях)

безопасным (права, RLS, валидация)

производительным (без лишних вызовов и запросов в цикле)

сопровождаемым (Git/EDT, обновляемость, тесты)

!Сквозной процесс от требований до релиза

Рамка практического проекта: какую подсистему делаем

Чтобы говорить предметно, возьмем учебно-производственный пример подсистемы «Продажи и склад».

Цель подсистемы

Пользователь должен:

Вести справочники (Номенклатура, Склады, Контрагенты).

Оформлять документы поступления и реализации.

При проведении контролировать остатки (не допускать отрицательных остатков).

Получать отчет по продажам за период.

Печатать простую форму по реализации (например, «Накладная»).

Граница проекта

Чтобы проект был завершенным, но не бесконечным, заранее фиксируем, что не делаем в первой версии:

Сложные партии, серийный учет, резервирование.

Себестоимость и расчет маржи.

Интеграции с внешними системами.

Это промышленная привычка: сначала делаем минимально полезный контур (MVP), затем развиваем.

Этап: ТЗ и критерии приемки

Что такое ТЗ в прикладном смысле

ТЗ — это договоренность о поведении системы. Для разработчика важнее всего не стиль документа, а наличие:

Сценариев работы.

Ограничений и правил.

Критериев приемки.

Исключений и ошибок.

Минимальный шаблон требований (удобный для разработки)

Используйте формат «Дано–Когда–Тогда», потому что он сразу превращается в тестовые сценарии.

Примеры для нашей подсистемы:

Дано: на складе есть 10 единиц товара A.

Когда: проводим реализацию на 12 единиц.

Тогда: проведение запрещено, сообщение содержит товар и доступный остаток.

Дано: документ реализации записан и проведен.

Когда: строим отчет «Продажи по номенклатуре» за период.

Тогда: в отчете есть строка по товару A с суммой и количеством.

Типовая декомпозиция требований в задачи

Чтобы довести до релиза, удобно сразу разложить требования на блоки работ.

| Блок | Что делаем | Результат для приемки | |---|---|---| | Модель данных | справочники/документы/регистры | можно вводить данные и хранить учетный результат | | Проведение | движения по регистрам, контроль остатков | учет корректен, отрицательные остатки не появляются | | Формы | формы объектов и списков, команды | пользователь проходит сценарий без "магии" | | Отчет/печать | СКД-отчет, макет печати | пользователь получает итог и печатный бланк | | Права | роли, (опционально) RLS | пользователь видит только нужное и может только разрешенное | | Качество/релиз | тесты, ревью, сборка, выпуск | изменение повторяемо, есть регресс |

Этап: проектирование данных (метаданные)

Этот этап напрямую опирается на темы про архитектуру конфигурации и проектирование данных.

Минимальная модель объектов

Справочники:

1. Номенклатура (например: Артикул, ЭтоУслуга). 2. Склады. 3. Контрагенты.

Документы:

1. ПоступлениеТоваров (приход на склад). 2. РеализацияТоваров (расход со склада).

Регистр накопления:

1. ТоварыНаСкладах (остатки). 1. Измерения: Склад, Номенклатура. 2. Ресурсы: Количество, Сумма.

!Карта объектов и связей подсистемы

Ключевые проектные решения (которые влияют на всё)

Где будет храниться итог?

1. Итог остатков и оборотов — в регистре, не в документах.

Какие разрезы учета нужны?

1. Если важны остатки по складам — склад должен быть измерением регистра.

Что должно быть обязательным?

1. Склад в документе реализации обязателен, иначе контроль остатков невозможен.

Этап: UX и управляемые формы

Этот этап опирается на темы про управляемые формы, события и клиент-сервер.

Принцип «тонкой формы»

Форма отвечает за:

Отображение реквизитов.

Команды пользователя.

Легкие UI-реакции.

Сервер отвечает за:

Запросы к данным.

Бизнес-правила.

Контроль и проведение.

Типовой набор форм

Для справочников:

1. форма списка 2. форма элемента

Для документов:

1. форма списка 2. форма объекта

Команды и события: как не испортить производительность

Правило: не дергать сервер на каждое ПриИзменении, если можно сделать пакетно или по кнопке.

Хороший шаблон:

Этап: проведение документов и контроль остатков

Этот этап опирается на тему про проведение и на тему про запросы.

Архитектурный шаблон проведения

В ОбработкаПроведения делайте:

Валидацию документа (заполненность, корректность строк).

Контроль остатков пакетным запросом.

Формирование движений.

Пакетный контроль остатков (идея)

Промышленный подход:

Собрать список номенклатуры из табличной части.

Одним запросом получить остатки по складу на дату.

Сравнить «потребность по документу» с остатками.

При нехватке — отказ с понятным сообщением.

Фрагмент (как скелет, без привязки к конкретной конфигурации):

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

Этап: отчеты и печатные формы

Этот этап опирается на темы про СКД, макеты и табличные документы.

Отчет на СКД (минимальная промышленная цель)

Отчет «Продажи по номенклатуре»:

Параметры:

1. ДатаНач 2. ДатаКон

Источник данных:

1. строки документа реализации или (лучше промышленно) движения регистра, если вы храните продажи в отдельном регистре.

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

Печатная форма

Печатная форма документа реализации:

Макет табличного документа с областями:

1. Шапка 2. Строка 3. Итоги

Серверный метод формирования ТабличныйДокумент.

Клиентская команда Печать только показывает результат.

Этап: права, (опционально) RLS и аудит

Этот этап опирается на тему безопасности.

Минимальный набор ролей для проекта

АдминистраторПодсистемы:

1. полные права в контуре подсистемы

МенеджерПродаж:

1. чтение справочников 2. создание/запись/проведение реализаций 3. просмотр отчета

Кладовщик:

1. создание/проведение поступлений 2. просмотр остатков

Главный принцип безопасности

Скрытая кнопка не равна запрету.

Если операция важная (проведение, изменение цены, массовое изменение), серверная логика должна перепроверить условия.

Когда стоит добавлять RLS в учебном проекте

RLS уместен, если вы моделируете реальную многоконтурность:

Несколько складов, и пользователь должен видеть только свои.

Несколько организаций в одной базе.

Если RLS внедряется, обязательно тестируйте производительность под ролью с ограничениями: RLS может утяжелять запросы.

Этап: производительность как часть определения готовности

Этот этап опирается на тему профилирования и оптимизации.

Минимальные правила, которые проверяем в проекте

Нет запросов «в цикле по строкам».

Нет массовых серверных вызовов из ПриИзменении.

В проведении остатки берутся пакетно.

В отчетах выбираются только нужные поля.

Практический прием: один серверный вызов на одну операцию

Если форма должна показать пользователю «остаток по всем строкам документа», правильная схема:

Клиент собирает параметры.

Клиент делает один вызов на сервер.

Сервер одним запросом получает всё и возвращает структуру/таблицу.

Этап: командная разработка и управление изменениями

Этот этап опирается на тему Git/EDT и на тему расширений.

Выбор способа хранения и совместной работы

В промышленной среде типовые варианты:

Хранилище конфигурации 1С.

Git + EDT.

Если проект на типовой конфигурации, отдельно решите, где будет доработка:

расширение (предпочтительно для обновляемости)

прямые правки типовой (крайний вариант)

Официальные справочные точки входа:

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

1C:Enterprise Development Tools

Минимальный регламент изменений

Ветка на задачу.

Небольшие коммиты.

Pull request.

Ревью с проверкой архитектурных рисков:

1. клиент-сервер 2. запросы в цикле 3. проведение и идемпотентность 4. права и безопасность

Этап: тестирование и критерии «готово»

Этот этап опирается на тему качества.

Какие тесты реально нужны в нашем проекте

Минимальный набор, который дает промышленную ценность:

Интеграционный сценарий проведения:

1. приход → остаток появился 2. расход в пределах остатка → проведен 3. расход сверх остатка → отказ

Сценарий отчета:

1. после проведенных реализаций отчет возвращает корректные итоги

Сценарий прав:

1. пользователь без роли не может проводить

Поддерживайте принцип из курса: чем больше логики в сервисах &НаСервереБезКонтекста, тем проще тестировать.

Инструменты экосистемы (как ориентиры):

xUnitFor1C

Vanessa Automation

BSL Language Server

Этап: релиз и постконтроль

Этот этап опирается на тему администрирования и выпуска.

Что входит в поставку подсистемы

Изменения конфигурации или расширения.

Обновление конфигурации базы данных (если менялись метаданные).

Изменения ролей и прав.

(При необходимости) обработка заполнения/миграции данных.

Чеклист релиза для практического проекта

В тестовом контуре выполнены ключевые сценарии:

1. ввод справочников 2. поступление 3. реализация 4. запрет отрицательных остатков 5. отчет 6. печать

Проверка под ролью ограниченного пользователя.

Проверка производительности на «длинном» документе (например, 200 строк):

1. проведение не выполняет запросы в цикле 2. форма не делает десятки серверных вызовов

Резервная копия перед выпуском.

Наблюдаемость (минимум)

Даже в учебном проекте полезно практиковать промышленную дисциплину:

Сообщения об ошибке проведения должны содержать контекст.

Ошибки интеграций (если появятся) должны логироваться.

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

Общие официальные страницы платформы (как точки входа в технологию):

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Итог: что считается «успешно завершенным практическим проектом»

Практический проект «подсистема от ТЗ до релиза» считается завершенным, если выполняются условия:

Есть согласованные требования и критерии приемки.

Данные спроектированы через правильные объекты (справочники/документы/регистры).

Документы проводятся, движения корректны, контроль остатков работает.

Формы реализованы по принципу тонкого клиента, бизнес-логика — на сервере.

Отчет и печать дают пользователю результат без скрытых пересчетов учета.

Права настроены, критичные ограничения не зависят от UI.

Нет базовых провалов производительности (запросов в цикле, лишних вызовов).

Изменения проходят командный процесс (VCS, ревью) и имеют минимальный регресс.

Выпуск выполняется по чеклисту и воспроизводим.

Эта статья — точка, где весь курс сходится в цельную промышленную практику: вы не просто «умеете делать объекты и писать код», вы умеете доводить подсистему до работающего, сопровождаемого релиза.

Установка, конфигуратор, клиент, сервер и базовые режимы работы

Как эта тема связана с предыдущей

В предыдущей статье мы разделили понятия платформа и конфигурация и разобрали основные компоненты системы: клиенты, сервер 1С и СУБД. Теперь переходим к практической основе: как установить среду, какими программами вы реально пользуетесь и в каких режимах работает 1С.

Что именно устанавливают в 1С

Под словом «установка 1С» часто подразумевают разные вещи. На практике обычно есть несколько установочных компонентов.

Платформа 1С:Предприятие — общая технологическая основа (клиентские приложения, сервер, служебные компоненты).

Информационная база (инфобаза) — конкретная база данных, где живут данные и прикладная логика конфигурации.

Конфигурация — прикладное решение (типовое или доработанное), которое загружается/обновляется в инфобазу.

Важно: платформа и инфобаза — это разные уровни. Платформа устанавливается на компьютер (или сервер), а инфобаза создается/подключается и затем используется из режима Предприятие.

!Схема показывает, что платформа — это программная среда, а инфобаза — место, где хранится конфигурация и данные

Где и как обычно ставят 1С в реальных проектах

Есть два самых частых сценария.

Учебный/локальный: один компьютер, файловая инфобаза, клиент и конфигуратор установлены локально.

Корпоративный: сервер 1С стоит на сервере (или нескольких), база данных — в СУБД, пользователи работают через тонкий клиент или веб-клиент.

Файловая и клиент-серверная инфобаза

Чтобы понимать дальнейшие шаги, зафиксируем термины.

Файловая инфобаза — хранится в каталоге на диске (в учебных задачах это самый быстрый старт).

Клиент-серверная инфобаза — хранится в СУБД, а подключение идет через сервер 1С.

С точки зрения разработчика это влияет на:

отладку и воспроизведение ошибок (локально проще поднять файловую базу)

производительность и параллельную работу (в промышленной среде почти всегда клиент-сервер)

работу с правами, регламентными заданиями, масштабированием (актуально в клиент-сервере)

Компоненты платформы: что такое конфигуратор, клиент и сервер

Конфигуратор

Конфигуратор — инструмент разработки и администрирования конфигурации в инфобазе. Через него делают:

создание и изменение метаданных (справочники, документы, регистры, роли)

разработку модулей (код), форм, команд

обновление конфигурации базы данных

отладку (в том числе подключение отладчика)

административные действия (частично): выгрузка/загрузка, обслуживание

Ключевая мысль: конфигуратор — это режим работы с конфигурацией, а не отдельная «другая программа» (хотя запускается как отдельный режим).

Режим 1С:Предприятие

Режим Предприятие — это то, чем пользуются конечные пользователи. Но разработчик тоже часто работает в этом режиме:

проверяет сценарии в формах

тестирует движения документов и записи в регистры

смотрит отчеты и печатные формы

проверяет права и ограничения

Клиенты: толстый, тонкий, веб

Клиент — это приложение, через которое пользователь подключается к инфобазе.

Толстый клиент — исторически основной клиент. Может выполнять заметную часть логики локально; сейчас чаще встречается в отдельных сценариях (например, когда это оправдано архитектурно или по наследию).

Тонкий клиент — наиболее распространенный вариант в корпоративной работе; основная бизнес-логика выполняется на сервере.

Веб-клиент — работа через браузер. Удобен для удаленного доступа, но накладывает ограничения на некоторые интерфейсные возможности и окружение.

Термины толстый/тонкий важны, потому что в 1С есть разделение кода по месту выполнения: клиент и сервер.

Сервер 1С:Предприятия

Сервер 1С — компонент платформы, который нужен для клиент-серверного варианта.

Он отвечает за:

выполнение серверного кода

управление соединениями и сессиями

фоновые задания (регламентные)

масштабирование (в том числе кластер)

взаимодействие с СУБД

В учебных задачах сервер может не понадобиться (если вы используете файловую базу), но для промышленной разработки понимание сервера обязательно.

Официальная справочная страница по платформе:

Платформа 1С:Предприятие 8

Установка платформы: базовая логика без привязки к конкретной ОС

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

Что выбрать при установке

На этапе обучения обычно достаточно:

клиентских компонентов (чтобы запускать Предприятие)

конфигуратора (чтобы разрабатывать)

Серверные компоненты нужны, если вы планируете развернуть клиент-серверную базу локально или в инфраструктуре.

Практическое правило:

если у вас файловая база и вы учитесь — ставьте клиент + конфигуратор

если вы тренируете промышленный сценарий — дополнительно ставьте сервер 1С и поднимаете СУБД

Типичный порядок установки в учебной среде

Установить платформу с компонентами клиент и конфигуратор.

Запустить стартовое окно (список информационных баз).

Добавить новую информационную базу (обычно файловую) или подключиться к существующей.

Открыть базу в конфигураторе и проверить, что вы можете читать/изменять конфигурацию.

Типичный порядок развертывания клиент-серверной среды (упрощенно)

Подготовить сервер 1С (установка серверных компонентов).

Подготовить СУБД (установка, создание базы, настройка пользователя/прав).

Создать клиент-серверную инфобазу и зарегистрировать ее на сервере.

Установить тонкий клиент на рабочие места (или настроить веб-клиент).

Настроить публикацию/подключение и права доступа.

Детали по СУБД и кластеру мы будем разворачивать дальше по курсу, когда дойдем до эксплуатации и производительности.

Стартовое окно и подключение к информационной базе

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

Обычно вы делаете одно из двух:

добавляете файловую базу (указываете каталог)

добавляете клиент-серверную базу (указываете сервер 1С и имя базы)

Что важно понимать про «подключение»

Подключение — это набор параметров:

где находится база (путь или сервер+имя)

как вы входите (пользователь, способ аутентификации)

в каком режиме запускаете (предприятие/конфигуратор)

Если на одном компьютере у вас несколько учебных баз, вы просто создаете несколько подключений.

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

Когда нужен конфигуратор

Используйте конфигуратор, когда вы:

меняете метаданные (добавляете реквизиты, документы, регистры)

пишете и редактируете код модулей

создаете/правите формы на уровне конфигурации

выполняете обновление конфигурации базы данных

Важный принцип: после изменения структуры метаданных обычно требуется применить изменения к базе данных (в терминах 1С — обновить конфигурацию базы данных). Иначе режим Предприятие может не увидеть вашу новую структуру.

Когда нужен режим предприятие

Используйте Предприятие, когда вы:

тестируете пользовательские сценарии

проверяете корректность движений документа и записей в регистры

проверяете отчеты, печатные формы, интерфейсные команды

проверяете роли и права доступа

Разработчик постоянно переключается между режимами: в конфигураторе строит, в предприятии проверяет, как это работает для пользователя.

!Цикл разработки: изменить — применить — проверить

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

Даже на базовом уровне важно запомнить:

часть кода выполняется на клиенте (обычно то, что связано с интерфейсом)

часть кода выполняется на сервере (обычно бизнес-логика и работа с данными)

Почему это важно:

производительность: лишние переходы клиент↔сервер дают задержки

безопасность: на клиенте нельзя хранить секреты и нельзя доверять входным данным

архитектура: тяжелые вычисления и доступ к данным чаще должны быть на сервере

Пока достаточно понимать сам факт разделения. В следующих темах курса мы разберем директивы компиляции и контекст выполнения (клиент/сервер) более предметно.

Минимальные правила безопасности и гигиены среды

Даже в учебной среде стоит сразу прививать правильные привычки.

Не работайте под полными правами без необходимости: для разработки и тестов можно иметь отдельного администратора и отдельного пользователя.

Делайте резервные копии перед серьезными изменениями конфигурации.

Фиксируйте версию платформы: ошибки и поведение могут отличаться между версиями.

Разделяйте учебные базы: одна база — один эксперимент, чтобы не ломать все сразу.

Частые проблемы новичков и как их диагностировать

«Изменил метаданные, но в предприятии ничего не появилось»

- Обычно забыли обновить конфигурацию базы данных.

«Не удается подключиться к клиент-серверной базе»

- Часто проблема в доступности сервера 1С, имени базы, портах, либо в учетных данных.

«В веб-клиенте не работает то, что работало в тонком»

- Это может быть ограничение веб-клиента или отличие окружения выполнения.

«Подключаюсь, но не вижу команд/разделов»

- Вероятно, права/роли пользователя или настройки интерфейса.

Инструменты разработчика: конфигуратор и EDT

В предыдущей статье мы упомянули два ключевых инструмента. Здесь зафиксируем позиционирование.

Конфигуратор — базовый инструмент, который есть почти везде и нужен всегда.

1C:Enterprise Development Tools (EDT) — среда разработки, полезная в командной разработке, при использовании Git и практиках промышленной разработки.

Официальная страница EDT:

1C:Enterprise Development Tools

Что дальше

После того как среда установлена и вы уверенно различаете конфигуратор, предприятие, клиент и сервер, следующий логичный шаг — перейти к практике работы с конфигурацией: создание основных объектов метаданных, их свойств и первых форм, а затем — к модулям и встроенному языку.

Архитектура прикладного решения: метаданные и объекты конфигурации

Связь с предыдущими темами

В первых статьях курса мы зафиксировали основу: платформа — это технологический слой (клиенты, сервер, язык, механизмы), а конфигурация — это прикладное решение, которое описывает бизнес-логику и структуру данных. Мы также разобрали, что разработчик работает в двух режимах: Конфигуратор (создание и изменение) и Предприятие (проверка работы глазами пользователя).

Теперь переходим к главному объекту внимания разработчика: архитектуре прикладного решения, которая в 1С задается через метаданные и объекты конфигурации.

Полезные официальные страницы (общие, но надежные как точки входа):

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Что такое метаданные и почему это основа архитектуры

Метаданные — это описание структуры приложения: какие сущности есть в системе, как они хранятся, как выглядят формы, какие есть команды, какие права доступа и какая логика выполняется.

Важно различать:

Данные — конкретные записи (например, элемент справочника Номенклатура или документ Реализация).

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

С точки зрения разработки метаданные — это «чертежи» прикладного решения. По ним платформа:

создает и поддерживает структуру хранения данных;

строит интерфейс (разделы, команды, формы);

определяет доступ (роли, права);

исполняет код модулей в правильном контексте.

!Дерево метаданных помогает увидеть, из каких классов объектов состоит конфигурация

Конфигурация как система: что считается «архитектурой» в 1С

В контексте 1С архитектура прикладного решения — это, в первую очередь:

разбиение функциональности на подсистемы и объекты;

модель данных (какие справочники, документы, регистры и как они связаны);

границы ответственности между объектами (что делает документ, что делает общий модуль, что уходит в отчет);

контуры исполнения (клиент/сервер, интерактивно/в фоне);

модель доступа (роли, права, ограничения).

Хорошая архитектура в 1С достигается не «сложными паттернами», а ясными правилами:

данные хранятся там, где им место (справочники/документы/регистры);

логика находится в ожидаемых местах (модули объектов, общие модули);

интерфейс собирается из подсистем и команд, а не «случайно как получилось»;

права проектируются одновременно с функциями, а не задним числом.

Объекты конфигурации: основные группы

Чтобы уверенно читать любую конфигурацию (типовую или кастомную), удобно мыслить группами объектов.

Объекты данных

Это объекты, которые определяют что хранится и какие бизнес-события фиксируются.

Справочники — относительно постоянные сущности (контрагенты, номенклатура, склады).

Документы — события и операции (поступление, реализация, перемещение).

Константы — одиночные значения (например, «Основная валюта»), которые редко меняются.

Объекты учета (регистры)

Это объекты, которые определяют как ведется учет и как получать итоги/остатки.

Регистры накопления — учет количеств и сумм (остатки/обороты).

Регистры сведений — хранение сведений во времени или по разрезам (например, цены по датам).

Регистры бухгалтерии — проводки (если используется бухгалтерская модель).

Регистры расчета — расчеты по периодам (например, сложные начисления).

Интерфейсные объекты

Они отвечают за то, как пользователь видит систему и как запускает действия.

Подсистемы — группировка функциональности и навигации.

Формы — интерфейс ввода/просмотра.

Команды — действия, доступные пользователю (кнопки, пункты меню).

Сервисные объекты

Они помогают выполнять операции и получать результаты.

Отчеты — аналитика, печатные формы (в широком смысле — вывод результатов).

Обработки — сервисные функции (загрузки, массовые изменения, помощники).

Объекты безопасности

Они определяют, кто что может делать.

Роли — набор прав.

Права — разрешения на чтение/запись/выполнение действий над объектами и данными.

Интеграционные объекты

Они обеспечивают взаимодействие с внешними системами.

HTTP-сервисы — собственные HTTP-эндпоинты.

Web-сервисы — SOAP-интеграции.

Планы обмена — обмены, репликации, распределенные решения (в зависимости от задач).

Анатомия объекта метаданных: из чего он обычно состоит

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

Типовая «карточка» объекта

Обычно у объекта есть:

Имя — техническое, используется в коде (Справочник.Номенклатура).

Синоним — человекочитаемое название в интерфейсе.

Комментарий — для разработчиков (почему так сделано, какие ограничения).

Реквизиты — поля объекта (например, Артикул, ЕдиницаИзмерения).

Табличные части — строки внутри объекта (например, строки товаров в документе).

Формы — формы списка, элемента, выбора и т.д.

Команды — что можно выполнить из интерфейса.

Модули — код, связанный с объектом.

Где у объекта «живет» код

Код распределяется по модулям. Даже до глубокого изучения языка важно понимать назначение.

| Где находится код | За что обычно отвечает | |---|---| | Модуль объекта | Бизнес-логика объекта, проверки, обработка записи/проведения | | Модуль менеджера | Логика «над множеством объектов» (поиск, создание, сервисные методы) | | Модуль формы | Реакция на действия пользователя, интерактивность интерфейса | | Общий модуль | Переиспользуемые процедуры/функции для разных объектов |

Принцип хорошей архитектуры: интерфейсная логика — ближе к формам, бизнес-логика и данные — ближе к объектам и общим модулям.

Подсистемы: скелет функционального разбиения

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

Подсистемы полезны, потому что:

задают понятную структуру решения (например, Продажи, Закупки, Склад);

помогают распределять объекты по областям ответственности;

упрощают настройку интерфейса (что показывать пользователю в каком разделе);

позволяют команде разработки договариваться на одном языке (где искать объект и логику).

Практическое правило: если объект «не лежит ни в одной подсистеме» и при этом используется пользователем, то интерфейс со временем станет хаотичным.

Справочники, документы и регистры: модель данных и модель учета

Справочники

Справочник хранит «список сущностей». Типичные свойства:

иерархия (папки/группы) — если нужна;

уникальность кода/наименования — если важно;

владельцы — если справочник подчинен другому объекту (например, Договоры подчинены Контрагентам).

Важно понимать отличие:

справочник — это что существует (например, товар);

документ — это что произошло (например, поступление товара);

регистр — это как считается учетный результат (остаток товара на складе).

Документы

Документ фиксирует событие и часто является источником движений в учетных регистрах.

Ключевые элементы документа:

реквизиты «шапки» (организация, контрагент, склад, дата);

табличные части (строки товаров/услуг);

проведение (если документ влияет на учет);

печатные формы (если нужно сформировать первичку).

Архитектурная мысль: документ — это не «экран ввода», а модель бизнес-события. Формы — только способ взаимодействия.

Регистры

Регистры отвечают за хранение учетных данных так, чтобы можно было быстро получать итоги.

Регистр накопления чаще всего отвечает на вопрос: сколько и на какую сумму?

Регистр сведений отвечает на вопрос: какое значение параметра актуально при таких условиях?

При проектировании важно:

определить измерения (по каким разрезам хранить данные: склад, номенклатура);

определить ресурсы (что накапливается: количество, сумма);

определить периодичность и требования к истории (хранить историю цен или только актуальную).

Формы и команды: как метаданные превращаются в UX

Форма — это объект интерфейса. Она может быть:

формой списка (показать множество записей);

формой элемента (редактировать одну запись);

формой выбора (подбор значения);

произвольной формой (мастер, рабочее место, панель).

Команда — это действие, которое пользователь запускает из формы, раздела или панели.

Архитектурные принципы для форм:

на форме — минимально необходимая логика, в основном управление UI;

проверки и расчеты, влияющие на данные, должны дублироваться на серверной стороне (чтобы нельзя было обойти их через другие сценарии);

тяжелые операции не должны выполняться «на каждое изменение поля», если это приводит к лишним клиент-серверным вызовам.

Общие модули: место для переиспользуемой логики

Общий модуль — это модуль, который не привязан к одному объекту и используется многими.

Зачем он нужен:

единые проверки и расчеты (например, форматирование номера, общие правила округления);

общие функции для работы с данными;

интеграционная логика (вынесенная из форм и объектов);

единый слой сервисов (например, «получить актуальную цену на дату»).

Риск плохой архитектуры: превращать общие модули в «свалку всего подряд». Хороший общий модуль обычно имеет четкую тему (например, РаботаСНоменклатурой, Печать, ИнтеграцияСCRM).

Права и роли: архитектура доступа как часть конфигурации

Роль — это набор разрешений на объекты, команды и данные.

Почему это архитектурная тема, а не «администрирование на потом»:

интерфейс и команды должны быть совместимы с правами (пользователь не должен видеть то, что не может выполнить);

права часто влияют на алгоритмы (например, разрешено ли менять цену, видеть себестоимость);

при росте системы исправление прав «задним числом» становится дорогим.

Минимальная практика для учебных проектов:

завести хотя бы две роли: Администратор и Пользователь;

проверить сценарии в режиме Предприятие под пользователем с ограниченными правами.

Как метаданные связаны с физическим хранением данных

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

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

Что происходит концептуально:

вы изменяете метаданные (добавили реквизит, табличную часть, регистр);

платформа сравнивает «как было» и «как стало»;

применяет изменения к структуре хранения (таблицам и служебным данным);

после этого режим Предприятие начинает видеть новую структуру.

Типичные последствия для разработчика:

если забыть обновить конфигурацию базы данных, новые реквизиты и объекты могут не появиться в работе;

изменения структуры данных требуют аккуратности (особенно в промышленной базе): могут быть длительные операции и блокировки;

в командной разработке важно синхронизировать изменения метаданных между участниками (иначе конфликты).

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

Минимальные правила проектирования метаданных (чтобы не переделывать)

Ниже — практичные правила, которые полезны даже в учебных базах.

Давайте объектам осмысленные имена: техническое имя должно быть читаемым и устойчивым.

Заполняйте синонимы: это напрямую влияет на качество интерфейса.

Пишите комментарии там, где есть бизнес-смысл: почему именно так, какие ограничения, откуда требование.

Не смешивайте уровни: формы — про UI, объект — про данные и правила, общий модуль — про общую логику.

Думайте о правах заранее: хотя бы на уровне «кто может видеть/создавать/проводить».

Как читать чужую конфигурацию: практический маршрут

Если вы открыли незнакомую конфигурацию и хотите быстро понять ее архитектуру, двигайтесь так:

Посмотрите подсистемы: какие функциональные блоки выделены.

Найдите ключевые справочники: какие сущности считаются базовыми.

Найдите ключевые документы: какие события фиксируются.

Посмотрите связанные регистры: как реализован учет.

Посмотрите общие модули: где лежит основная бизнес-логика.

Посмотрите роли: какие сценарии реально предусмотрены для пользователей.

Что дальше по курсу

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

Следующий логичный переход — к практике: созданию базовых объектов (справочник, документ, регистр), настройке форм и написанию первых модулей с учетом разделения клиент/сервер и принципов архитектурной чистоты.

Справочники, документы, регистры: проектирование структуры данных

Связь с предыдущими темами

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

В этой статье переходим к ядру любой учетной системы: как спроектировать структуру данных через справочники, документы и регистры, чтобы:

пользователю было понятно, что вводить и в каком месте;

учетные итоги считались надежно и быстро;

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

Модель предметной области в терминах 1С

Удобная ментальная модель для проектирования в 1С выглядит так:

Сущности бизнеса описываем справочниками и константами.

События фиксируем документами.

Результаты учета храним и получаем через регистры.

Если формализовать вопросами:

Что существует относительно постоянно? → справочники.

Что произошло в конкретный момент времени? → документы.

Какие итоги должны быстро получаться по разрезам и периодам? → регистры.

!Схема: сущности → события → итоги учета

Справочники

Справочник предназначен для хранения относительно постоянных данных: номенклатуры, контрагентов, складов, сотрудников, договоров.

Когда выбирать справочник

Справочник подходит, если выполняются условия:

значение многократно используется в разных местах;

у сущности есть свойства, которые нужно хранить и изменять;

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

Если значение единичное для всей базы, часто лучше использовать константу. Если значение вычисляется или приходит извне и не требует «карточки» объекта, справочник может оказаться избыточным.

Что важно спроектировать в справочнике

У справочника обычно есть стандартные поля Код и Наименование, а также ваши реквизиты.

Ключевые решения проектирования:

Иерархия

1. Без иерархии: плоский список. 2. Иерархия групп и элементов: папки для классификации. 3. Иерархия элементов: когда сам элемент может содержать подэлементы.

Уникальность кода и наименования

1. Если пользователи опираются на артикул, SKU, табельный номер, стоит подумать о контроле уникальности. 2. Если наименование не уникально в реальности, запрещать дубли наименований обычно вредно.

Владельцы и подчиненность

1. Подчиненные справочники применяются, когда сущность логически принадлежит другой. 2. Пример: Договоры подчинены Контрагентам.

Реквизиты ссылочного типа

1. Реквизит типа СправочникСсылка.Номенклатура хранит ссылку на элемент. 2. Это основной механизм связей между сущностями.

Типичные ошибки при проектировании справочников

Делать отдельный справочник для каждого «списка значений», где достаточно перечисления или константы.

Хранить в справочнике то, что является событием.

Использовать справочник как «журнал операций», добавляя элемент на каждое действие пользователя.

Документы

Документ фиксирует событие хозяйственной деятельности: поступление, реализацию, перемещение, списание, оплату.

Из чего состоит документ

Практически любой документ в 1С включает:

Реквизиты шапки

1. Дата. 2. Организация. 3. Контрагент. 4. Склад.

Табличные части

1. Строки товаров/услуг. 2. Количество, цена, сумма, ставка НДС и другие колоночные реквизиты.

Проведение

1. При проведении документ формирует движения по регистрам. 2. Именно проведение превращает «ввод данных» в «учетное событие».

Нумерация и жизненный цикл

1. Номер обычно уникален в пределах периода. 2. В промышленной разработке важно думать о перепроведении и изменении задним числом.

Документ и учет: важное различие

Документ хранит факт и детали события.

Регистр хранит учетный результат, оптимизированный для получения итогов.

Практическое следствие: не пытайтесь получать остатки «суммированием табличных частей документов» в отчетах. Это почти всегда приводит к проблемам производительности и сложности.

Типичные ошибки при проектировании документов

Пытаться сделать один «универсальный документ на все случаи», который со временем превращается в непредсказуемый комбайн.

Смешивать в одном документе разные по смыслу события.

Делать критически важные проверки только на форме, а не в логике объекта и проведения.

Регистры

Регистр в 1С нужен для учета и быстрых итогов. Регистры проектируются так, чтобы ответы на вопросы бизнеса получались эффективно:

Сколько товара на складе?

Какая была цена на дату?

Какие обороты по номенклатуре за период?

Базовые элементы регистра

У большинства регистров встречаются понятия:

Измерения: разрезы учета, по которым группируются итоги.

Ресурсы: то, что накапливается или хранится как результат.

Реквизиты: дополнительные поля записи, которые не участвуют в итогах как ресурсы.

Пример идеи:

измерения: Склад, Номенклатура;

ресурсы: Количество, Сумма.

Регистры накопления

Регистр накопления отвечает на вопросы остатков и оборотов.

Ключевые понятия:

Вид регистра

1. Остатки: хранит состояние на момент времени. 2. Обороты: ориентирован на оборотные показатели.

Движения

1. Записи создаются документами при проведении. 2. Движения бывают приход и расход.

Период

1. Регистр привязан ко времени, чтобы можно было считать итоги на любую дату.

Регистры сведений

Регистр сведений хранит значения параметров по условиям и, при необходимости, во времени.

Частые сценарии:

цены номенклатуры на дату;

курсы валют;

настройки, зависящие от организации, склада, договора.

Важные решения:

Периодичность

1. Непериодический: значение просто «актуальное по ключу». 2. Периодический: значение меняется со временем.

Ключ записи

1. Обычно формируется измерениями. 2. Чем стабильнее и понятнее ключ, тем проще поддержка.

Коротко про другие регистры

Иногда используются и другие виды:

Регистр бухгалтерии: если система ведет учет проводками.

Регистр расчета: если нужны сложные периодические расчеты с вытеснениями и зависимостями.

Для старта промышленной разработки чаще всего достаточно уверенно владеть регистрами накопления и сведений.

!Сравнение структуры записей регистра накопления и регистра сведений

Как выбрать правильный объект: практический алгоритм

Чтобы не «угадать», а спроектировать осознанно, используйте следующий порядок.

Зафиксируйте список сущностей предметной области.

Для каждой сущности ответьте:

1. Нужна ли ей карточка и повторное использование? → справочник. 2. Достаточно ли одного значения на всю базу? → константа.

Зафиксируйте список событий.

Для каждого события ответьте:

1. Должно ли оно иметь номер и дату? → документ. 2. Должно ли оно попадать в журнал и печататься? → документ.

Зафиксируйте список учетных результатов.

Для каждого результата ответьте:

1. Это остатки/обороты? → регистр накопления. 2. Это значение параметра по условиям и датам? → регистр сведений.

Определите разрезы учета.

Определите показатели.

Проверьте, какие документы должны делать движения в какие регистры.

Мини-пример проектирования: склад и продажи

Ниже пример, который удобно держать как «эталон минимальной модели».

Справочники

| Справочник | Зачем нужен | Примеры реквизитов | |---|---|---| | Номенклатура | список товаров и услуг | Артикул, ЕдиницаИзмерения, ЭтоУслуга | | Склады | места хранения | Адрес, Ответственный | | Контрагенты | покупатели и поставщики | ИНН, Телефон, ВидКонтрагента | | ВидыЦен | классификация цен | Валюта, ПризнакПоУмолчанию |

Документы

| Документ | Смысл события | Типовая табличная часть | |---|---|---| | ПоступлениеТоваров | товар пришел на склад | Номенклатура, Количество, Цена, Сумма | | РеализацияТоваров | товар продан | Номенклатура, Количество, Цена, Сумма |

Регистр накопления для остатков

Регистр: ТоварыНаСкладах.

| Тип поля | Состав | |---|---| | Измерения | Склад, Номенклатура | | Ресурсы | Количество, Сумма |

Логика движений:

Документ ПоступлениеТоваров делает приход.

Документ РеализацияТоваров делает расход.

Регистр сведений для цен

Регистр: ЦеныНоменклатуры.

| Тип поля | Состав | |---|---| | Измерения | Номенклатура, ВидЦены | | Ресурс | Цена | | Периодичность | обычно периодический |

Смысл: цена может меняться во времени, и в документах нужно получать актуальную цену на дату.

Проектирование с учетом промышленной разработки

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

Стабильные имена и предсказуемая структура

Технические имена объектов должны быть устойчивыми и понятными.

Синонимы должны быть человеческими, потому что они формируют интерфейс.

Разделение ответственности

В справочниках храним свойства сущностей, а не учетные итоги.

В документах фиксируем факты и делаем движения.

В регистрах храним учетные результаты и получаем итоги.

Изменения метаданных и база данных

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

Производительность начинается с модели данных

Чем больше «аналитик» вы кладете в измерения, тем сложнее и тяжелее итоги.

Чем меньше измерений, тем проще и быстрее итоги, но меньше детализация.

Выбор измерений и ресурсов — компромисс между детализацией и скоростью.

Права доступа

Права стоит продумывать одновременно со структурой:

кто может создавать и проводить документы;

кто может менять справочники;

кто может видеть себестоимость или цены.

Что дальше

После того как вы научились выбирать между справочником, документом и регистром и проектировать измерения и ресурсы, следующий шаг в практике разработки обычно такой:

создать эти объекты в конфигураторе;

построить базовые формы;

реализовать проведение документов и движения по регистрам;

научиться проверять результаты в режиме Предприятие.

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

Язык 1С: синтаксис, типы, коллекции и модули

Связь с предыдущими темами

В предыдущих статьях мы разобрали, как устроена платформа 1С:Предприятие, что такое метаданные и почему прикладное решение проектируют через справочники, документы и регистры. Теперь добавляем следующий обязательный слой: как именно записывается логика.

Встроенный язык 1С используется, чтобы:

реализовать бизнес-правила (проверки, расчеты, проведения документов)

связать интерфейс с данными (реакции формы на действия пользователя)

организовать повторно используемые сервисы (общие модули)

управлять контекстом выполнения (клиент/сервер)

Официальные точки входа в технологию (как контекст курса):

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

!Где живет код 1С и как ходят вызовы между клиентом и сервером

Общие свойства встроенного языка

Встроенный язык 1С часто называют BSL (Business Scripting Language). На практике важно запомнить несколько особенностей, которые влияют на стиль кода и отладку.

Язык регистронезависимый: Сообщить, сообщить и СООБЩИТЬ воспринимаются одинаково.

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

Комментарии:

Основные строительные блоки кода: процедуры и функции.

Переменные и область видимости

Локальные переменные

Локальные переменные создаются присваиванием.

Практический смысл:

локальная переменная живет только внутри процедуры или функции

имя переменной выбирайте так, чтобы оно читалось как роль в алгоритме: СуммаДокумента, ТекущаяЦена, СкладОтгрузки

Модульные переменные

Переменные уровня модуля объявляются ключевым словом Перем. Их видно всем процедурам и функциям этого модуля.

Рекомендация для промышленной разработки:

модульные переменные используйте осторожно, потому что они усложняют сопровождение и тестирование

если без состояния нельзя, фиксируйте в комментарии зачем оно нужно и когда очищается

Значения Неопределено и проверки заполненности

В 1С часто встречается значение Неопределено.

Типичный сценарий: реквизит не заполнен или переменная еще не инициализирована.

Для многих прикладных сценариев удобнее использовать ЗначениеЗаполнено().

Процедуры и функции

Разница

Процедура выполняет действия и не возвращает результат.

Функция возвращает результат через Возврат.

Параметры и ясность контракта

Практика, которая сильно повышает качество кода:

функция должна быть предсказуемой: одинаковые входные параметры → одинаковый результат

если функция меняет данные, это должно быть явно видно по имени и месту вызова

Управляющие конструкции

Условие

Циклы

Цикл Для:

Цикл Пока:

Цикл по коллекции Для Каждого:

Управление циклом:

Прервать завершает цикл

Продолжить переходит к следующей итерации

Обработка ошибок

Основная конструкция обработки исключений:

Практический принцип:

исключения используйте для нештатных ситуаций

для ожидаемых ветвлений (например, не найдено) обычно лучше обычные проверки

Типы данных: что важно знать разработчику

В 1С есть набор базовых типов и большой слой прикладных типов, связанных с метаданными.

Базовые типы

На практике чаще всего встречаются:

Число

Строка

Дата

Булево (значения Истина и Ложь)

Неопределено

Пример:

Ссылочные типы прикладного решения

Когда вы создаете метаданные (справочники, документы), в языке появляются ссылочные типы.

Примеры того, как их обычно видит разработчик:

СправочникСсылка.Номенклатура

ДокументСсылка.РеализацияТоваров

Принципиальная идея:

ссылка хранит указатель на объект в базе

сам объект получают через методы вроде ПолучитьОбъект() (в зависимости от сценария)

Как узнать тип значения

Для диагностики и защитных проверок используют ТипЗнч().

Рекомендация:

проверки типов полезны в общих модулях и интеграциях

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

Преобразование типов

Часто применяют явное преобразование:

Практический совет:

не полагайтесь на неявные преобразования в сложных местах, особенно в расчетах и интеграциях

Коллекции: основные контейнеры данных

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

Массив

Массив подходит для упорядоченного списка.

Когда выбирать:

нужен порядок

доступ по индексу

Структура

Структура хранит пары ключ-значение, где ключ обычно строка.

Когда выбирать:

вы передаете набор именованных параметров

хотите читабельный доступ Параметры.Склад

Соответствие

Соответствие тоже контейнер ключ-значение, но обычно более универсален по ключам.

Когда выбирать:

ключом является не строка, а, например, ссылка на справочник

нужен быстрый поиск по ключу

ТаблицаЗначений

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

Когда выбирать:

результат по смыслу табличный

нужны фильтрация, сортировка, группировки на уровне структуры данных

СписокЗначений

СписокЗначений часто встречается в интерфейсных сценариях: заполнение списков выбора, подбор значений.

Ключевая идея:

это коллекция элементов, у каждого есть значение и представление

Что выбрать: краткая таблица

| Задача | Чаще всего подходящая коллекция | |---|---| | Список значений по порядку | Массив | | Набор параметров по именам | Структура | | Быстрый поиск по ключу | Соответствие | | Табличный результат | ТаблицаЗначений | | UI-списки выбора | СписокЗначений |

Модули в 1С: где живет код

В 1С код организован по модулям. Важно не просто уметь писать синтаксис, а класть логику в правильные места, чтобы решение было сопровождаемым.

Основные виды модулей

| Модуль | Где находится | Типичная ответственность | |---|---|---| | Модуль объекта | внутри конкретного объекта (документ, справочник) | правила записи, проведение, проверки данных | | Модуль менеджера | у менеджера объекта | операции над множеством объектов, фабричные методы, сервисные функции | | Модуль формы | у формы списка/элемента | интерактивность, обработчики событий UI | | Общий модуль | отдельный объект метаданных | переиспользуемая логика, сервисы, утилиты | | Модуль сеанса | на уровне приложения | логика на старт сессии пользователя |

Практический принцип архитектуры:

UI-логика должна быть ближе к формам

бизнес-правила и работа с данными должны быть ближе к объектам и общим модулям

!Сопоставление типов модулей и контекстов выполнения

Экспорт процедур и функций

Чтобы процедура или функция была доступна из других модулей, используется Экспорт.

Рекомендация:

экспортируйте только то, что является частью контракта модуля

внутренние вспомогательные функции оставляйте неэкспортными

Клиент и сервер: директивы контекста выполнения

Одна из самых частых причин ошибок новичков в 1С: попытка выполнить серверную операцию на клиенте или наоборот.

Для явного указания контекста используются директивы перед процедурой или функцией.

Базовые директивы

&НаКлиенте для кода, который должен выполняться в клиентском контексте (обычно логика формы)

&НаСервере для кода, который должен выполняться на сервере (обычно работа с данными)

&НаСервереБезКонтекста для серверного кода без доступа к контексту формы (часто полезно для чистых сервисных функций)

Пример разделения:

Практический смысл:

на клиенте не должно быть тяжелой логики и прямой работы с хранилищем данных

на сервере должны быть проверки, которые нельзя обойти альтернативным сценарием (например, загрузкой данных или внешним вызовом)

Препроцессор: компиляция под разные условия

В 1С есть препроцессорные директивы, которые позволяют включать или исключать фрагменты кода в зависимости от условий компиляции.

Часто встречается формат:

Также используются директивы оформления и навигации по коду:

#Область

#КонецОбласти

Практический совет:

препроцессор полезен, но им легко ухудшить читаемость

если логика системная, чаще лучше разделять ее по модулям и директивам &НаКлиенте и &НаСервере, а не множить #Если

Минимальные правила промышленного стиля кода

Ниже набор правил, которые стоит применять сразу, даже в учебной базе.

Пишите маленькие функции и процедуры, которые делают одно действие.

Держите UI-логику на форме, а бизнес-правила на сервере.

Повторяющийся код выносите в общий модуль, но не превращайте общий модуль в свалку.

Явно проверяйте входные параметры на сервере.

Избегайте лишних клиент-серверных вызовов в обработчиках событий формы.

Что дальше

После понимания синтаксиса, типов, коллекций и модульной структуры можно переходить к прикладной практике:

писать код в модулях объектов для документов и справочников

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

получать данные запросами и формировать табличные результаты для интерфейса и отчетов

Именно связка метаданные → регистры → код модулей → клиент/сервер делает разработчика 1С эффективным в реальных проектах.

Событийная модель, контексты выполнения и клиент-серверное разделение

Связь с предыдущими темами курса

Ранее мы разобрали метаданные и объекты конфигурации (где живут данные), а затем — основы языка 1С, модули и директивы &НаКлиенте и &НаСервере (где живет код). Теперь соберем это в практическую картину: как код исполняется во времени.

В 1С разработка почти всегда событийная:

пользователь что-то сделал в форме

платформа вызвала обработчик события

обработчик, при необходимости, обратился на сервер

сервер выполнил бизнес-логику и работу с данными

результат вернулся на клиент и отразился в интерфейсе

Понимание событий и контекстов выполнения — это основа промышленной разработки, потому что ошибки здесь приводят к:

лишним клиент-серверным вызовам и задержкам

неустойчивым проверкам (проверили на форме, но обошли через другой сценарий)

невозможности выполнить код в веб-клиенте

проблемам безопасности (логика и данные оказались «на клиенте»)

!Общая картина: события на форме запускают обработчики, тяжелая логика и данные — на сервере

Что такое событийная модель в 1С

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

Источники событий в типичной конфигурации:

события форм (пользовательский интерфейс)

события объектов (жизненный цикл записи данных)

события проведения документа (формирование движений)

события подписок на события (централизованная реакция на запись/проведение)

фоновые и регламентные сценарии (по расписанию, вне UI)

Дальше мы сфокусируемся на трех ключевых вещах для разработчика:

события в формах

события объектов и проведения

контексты выполнения и границы клиент↔сервер

События форм: где чаще всего «начинается» логика

Форма в управляемом приложении — основной слой, где происходит взаимодействие пользователя с системой. Важно помнить: форма не обязана «владеть истиной». Форма — это удобный UI, но критичные правила должны жить на сервере.

Типовые события формы

Ниже — наиболее встречающиеся события и их смысл.

| Событие формы | Когда возникает | Что обычно делают | Типичные ошибки | |---|---|---|---| | ПриОткрытии | форма открылась и показана пользователю | заполнение элементов, первичная инициализация | тяжелая загрузка данных без необходимости | | ПриСозданииНаСервере | форма создается на сервере | подготовка данных формы на сервере | смешивание UI-логики с серверной | | ПриИзменении (у реквизита формы) | пользователь изменил значение поля | легкая реакция UI, запуск пересчета через сервер | вызов сервера на каждый ввод символа | | Нажатие (команда/кнопка) | пользователь нажал команду | запуск явного действия: расчет, подбор, заполнение | выполнение бизнес-логики на клиенте |

Пример: кнопка вызывает серверный расчет

Типовой промышленный прием: клиентская процедура минимальна и вызывает серверный метод.

Ключевая идея:

клиент отвечает за UI и запуск действий

сервер отвечает за правила и расчеты

События объекта: где должны жить правила данных

Объектные события возникают, когда платформа записывает объект (элемент справочника, документ) в базу. Эти события критичны, потому что запись может происходить разными способами:

из формы

из обработки

из обмена

из внешнего соединения

Поэтому все правила, которые должны быть истинны всегда, размещают в модуле объекта, а не только в форме.

Типовой жизненный цикл записи

Точная последовательность может зависеть от типа объекта и режима, но концептуально процесс такой:

платформа готовится записать объект

выполняются проверки и подготовка данных

выполняется запись

при необходимости выполняются действия после записи

Типовые обработчики модуля объекта

| Событие объекта | Назначение | Что обычно делают | |---|---|---| | ПередЗаписью | последняя точка для проверок перед записью | проверки заполненности, ограничения, нормализация данных | | ПриЗаписи | реакция на факт записи | сервисные действия, фиксация следов, обновление связанных данных |

Пример проверки в ПередЗаписью:

Практический принцип:

проверка в форме улучшает удобство

проверка в объекте обеспечивает неизбежность правила

Проведение документов как отдельная «ветка событий»

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

Концептуально:

запись фиксирует сам документ как факт и хранит реквизиты

проведение фиксирует влияние документа на учет (регистры)

Где живет код проведения

В учебных и многих практических конфигурациях логика проведения размещается в обработчике проведения документа в модуле объекта.

Смысл промышленного разделения ответственности:

документ отвечает за корректность движений

регистры отвечают за итоги

формы не должны «рисовать учет», они должны запускать стандартные механизмы

Подписки на события: централизованная реакция (когда объектов много)

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

Типовые применения:

аудит: логировать изменения объектов

единые проверки, которые распространяются на множество документов

унифицированные реакции на проведение

Риск неправильного применения:

превращать подписки на события в «скрытую магию», из-за которой сложно понять, почему поведение изменилось

Практика:

используйте подписки для кросс-объектных правил

если правило относится к одному объекту, держите его в модуле объекта

Контекст выполнения: что значит «клиент», «сервер» и «без контекста»

В управляемом приложении код может исполняться в разных контекстах. Упрощенно — есть два мира.

клиент: интерфейс, события формы, реакция на действия пользователя

сервер: бизнес-логика, работа с данными, запросы, движения, тяжелые расчеты

Директивы контекста выполнения

Используются директивы перед процедурой или функцией.

| Директива | Где выполняется | Когда применять | |---|---|---| | &НаКлиенте | на клиенте | UI, обработчики команд, изменение элементов формы | | &НаСервере | на сервере | бизнес-правила, обращение к данным, расчеты | | &НаСервереБезКонтекста | на сервере без доступа к контексту формы | сервисные функции, которые должны быть «чистыми» и переиспользуемыми |

Что означает «без контекста»

У серверного кода без контекста нет доступа к переменным и объектам формы. Это полезно, потому что:

функция становится переиспользуемой из разных мест

меньше риск случайно «потащить» форму в серверную логику

проще тестировать и сопровождать

Пример разделения на «тонкий клиент» и «чистый сервис»:

Клиент↔сервер: стоимость вызова и как проектировать без «дерганья»

Каждый клиент-серверный вызов имеет стоимость: сетевую задержку, сериализацию параметров, время выполнения на сервере.

Плохой сценарий: вызывать сервер на каждое событие ПриИзменении, особенно если пользователь вводит данные постепенно.

Типовые практики снижения количества вызовов

Делайте пересчеты по явной команде пользователя, если расчет тяжелый.

Используйте «пакетные» вызовы: один вызов получает сразу все нужные данные.

На ПриИзменении делайте только UI-реакции, а тяжелую логику переносите на ПриОкончанииВвода (если применимо) или на кнопку.

Правило размещения логики

если логика меняет данные или зависит от данных базы, она должна быть на сервере

если логика только меняет отображение (видимость, доступность, подсказки), она обычно на клиенте

Где проверять данные: форма, объект, серверный сервис

Новички часто делают проверки только на форме, потому что так быстрее увидеть результат. В промышленной разработке этого недостаточно.

Правильная схема слоев:

форма: подсказки, ранние проверки для удобства

объект: обязательные проверки, без которых запись недопустима

серверные общие модули: переиспользуемые проверки и расчеты

Пример распределения:

форма подсветила, что не выбран склад

объект в ПередЗаписью запретил запись без склада

общий модуль предоставил функцию ПроверитьЗаполнениеРеквизитов() для переиспользования

Типичные ошибки событийной разработки и как их предотвращать

Ошибка: бизнес-правило только на клиенте

Последствия:

правило можно обойти через другой сценарий записи

поведение расходится между тонким клиентом и веб-клиентом

Профилактика:

дублируйте критичные проверки в модуле объекта или серверном сервисе

Ошибка: много серверных вызовов из событий формы

Последствия:

форма «тормозит»

сервер перегружен мелкими вызовами

Профилактика:

группируйте запросы

запускайте тяжелые действия по команде

Ошибка: смешивание UI и бизнес-логики

Последствия:

код сложно переносить и переиспользовать

трудно тестировать

Профилактика:

форма вызывает серверные функции

серверные функции не знают о форме

Минимальный «чеклист» перед тем как писать обработчик события

Перед добавлением кода в событие формы или объекта проверьте:

это UI-логика или бизнес-логика

нужен ли доступ к базе данных

сколько раз это событие может сработать за один сценарий пользователя

можно ли сделать один серверный вызов вместо нескольких

должно ли правило срабатывать при записи любым способом

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

Материалы общего уровня, которые помогают ориентироваться в технологиях платформы и средах разработки:

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

1C:Enterprise Development Tools

Что дальше по курсу

После событийной модели и понимания клиент-серверного разделения следующий шаг — закрепить практику в прикладной задаче:

создать документ и регистр

реализовать проведение и движения

сделать форму, которая минимально содержит логику и вызывает сервер

научиться диагностировать лишние вызовы и переносить логику в правильный слой

Это будет мостом от «умения писать код» к «умению строить устойчивую промышленную логику».

Управляемые формы: реквизиты, команды, элементы и навигация

Связь с предыдущими темами курса

Ранее мы разобрали:

как прикладное решение описывается метаданными (справочники, документы, регистры);

как код распределяется по модулям;

почему важно клиент-серверное разделение и событийная модель.

Управляемые формы связывают эти темы в единую практику: пользователь работает в интерфейсе, форма генерирует события, критичная логика выполняется на сервере, а форма лишь управляет отображением и запуском действий.

Эта статья дает устойчивую модель: что такое управляемая форма, из чего она состоит (реквизиты, команды, элементы), и как правильно организовывать навигацию в приложении.

!Схема показывает, что элементы отображают реквизиты, команды запускают обработчики, а бизнес-логика уходит на сервер

Что такое управляемая форма

Управляемая форма — это форма в управляемом приложении 1С, где:

интерфейс строится из элементов формы;

элементы привязываются к реквизитам формы (данным формы);

действия пользователя оформляются как команды;

логика реагирует на события (обработчики в модуле формы и модулях объектов);

значимая работа с данными и правилами обычно выполняется на сервере.

Ключевое отличие от подхода «форма как место всей логики»: управляемая форма — это слой UI, а не центр бизнес-логики.

Анатомия формы: реквизиты, элементы, команды

Реквизиты формы

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

Важная мысль: реквизит формы не обязан на 100% совпадать с реквизитом объекта метаданных.

Реквизиты формы часто бывают трех типов:

Реквизиты, связанные с объектом: показывают и редактируют данные документа/справочника.

Реквизиты формы для UI-сценария: например, "Показывать только доступные", "РежимПодбора".

Реквизиты для табличных отображений: например, таблица значений для результата расчета или подбора.

#### Пример: реквизит объекта и реквизит формы — разные уровни Ситуация в документе продажи:

в объекте документа есть реквизит Склад;

на форме есть реквизит Склад (привязан к объекту);

на форме есть реквизит ДоступныйОстаток (расчетный, в объекте его может не быть).

Практическое правило промышленной разработки:

если значение должно сохраняться и быть частью данных — оно должно жить в объекте (или в регистре/справочнике);

если значение нужно только для отображения или интерактивного сценария — держите его на форме.

Элементы формы

Элемент формы — это визуальная часть интерфейса: поле ввода, таблица, кнопка, группа, переключатель, командная панель.

У элемента обычно есть:

Имя (техническое, для доступа из кода через ЭтаФорма.Элементы.<Имя>);

свойства отображения (видимость, доступность, заголовок);

привязка к данным (к реквизиту формы или реквизиту объекта).

Примеры типичных элементов:

поле ввода ПолеВводаСклад привязано к реквизиту Склад;

таблица ТаблицаТовары привязана к табличной части (или таблице значений);

кнопка КнопкаЗаполнить запускает команду.

#### Управление элементами из кода Обычно это клиентская логика (UI-уровень):

Здесь Склад — реквизит формы (или реквизит объекта, доступный на форме), а ТаблицаТовары — элемент формы.

Команды

Команда — это декларация действия, которое пользователь может выполнить. Команда может быть размещена:

на форме (кнопка, пункт меню, командная панель);

в командном интерфейсе раздела;

в списке объектов (например, команда создания документа).

Команда обычно связана с обработчиком в модуле формы.

Пример обработчика команды на клиенте с вызовом сервера:

Практический принцип:

команда запускается на клиенте (пользователь нажал);

работа с данными и правилами — на сервере;

форма отражает результат.

Источники данных формы: объект, табличная часть, произвольные данные

В управляемом приложении форма чаще всего работает в одном из сценариев:

Форма объекта (элемента справочника, документа).

Форма списка (список документов/справочников).

Произвольная форма (рабочее место, панель, мастер, отчетная форма).

Форма объекта

Для документов и справочников ключевой источник данных — сам объект (его реквизиты и табличные части). Поэтому:

реквизиты формы часто привязаны к реквизитам объекта;

события записи должны поддерживаться не только формой, но и модулем объекта.

Промышленное правило:

удобные подсказки и ранние проверки можно делать на форме;

обязательные проверки должны находиться в модуле объекта (например, ПередЗаписью).

Форма списка

Форма списка работает с выборкой данных и действиями над множеством объектов:

поиск, фильтры, отборы;

создание/открытие объектов;

групповые операции (если допустимо правами).

Ошибки новичков в списках:

загружать в форму слишком много данных без ограничений;

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

Произвольные формы

Произвольные формы обычно опираются на реквизиты формы (структуры, таблицы значений, параметры) и серверные методы:

рабочие места ("Панель менеджера продаж");

мастера ("Помощник создания заказа");

формы подбора.

Здесь особенно важно отделять UI от сервиса: форма вызывает серверные методы, сервер возвращает структуру или таблицу значений.

События формы: какие бывают и где выполнять логику

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

Часто используемые события

| Событие | Где полезно | Типичный смысл | Риск неправильного применения | |---|---|---|---| | ПриСозданииНаСервере | на сервере | инициализация данных формы, подготовка реквизитов | тянуть UI-логику на сервер | | ПриОткрытии | на клиенте | настройка отображения, стартовые действия UI | запуск тяжелых запросов без нужды | | ПриИзменении у реквизита | на клиенте | легкая реакция интерфейса | слишком частые вызовы сервера | | Нажатие у команды | на клиенте | запуск действия | выполнять бизнес-логику на клиенте |

Паттерн: подготовить данные на сервере, показать на клиенте

Здесь важно, что серверная функция сделана &НаСервереБезКонтекста: она не зависит от формы и может переиспользоваться.

Навигация в управляемом приложении

Навигация отвечает на вопрос: как пользователь попадает к нужному действию или данным.

В управляемом приложении она обычно строится через:

подсистемы (разделы интерфейса);

командный интерфейс (что видно в разделе);

формы (списка, объекта, выбора);

программное открытие форм (переходы из одного сценария в другой).

!Иллюстрация показывает типовой путь пользователя и место программной навигации

Подсистемы и командный интерфейс

Подсистема задает функциональный раздел (например, Продажи, Склад). Внутри раздела пользователь видит команды:

открыть список документов;

создать документ;

открыть справочник;

запустить отчет или обработку.

Практические рекомендации:

размещайте объект в тех подсистемах, где он реально используется;

не перегружайте раздел десятками команд;

учитывайте права: пользователь не должен видеть команды, которые не может выполнить.

Открытие форм из кода

Самый распространенный механизм навигации из формы — открытие другой формы по имени.

Пример: открыть форму списка справочника с клиентского кода:

Пример: открыть форму объекта и передать параметры.

Важно: точные параметры зависят от того, какую форму вы открываете и что она ожидает. В промышленной практике параметры фиксируют как контракт: форма документирует, что она принимает.

Практический принцип:

навигация и UI — на клиенте;

подготовка данных для формы (если нужно) — на сервере;

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

Привязки данных: как элементы получают значения

Чтобы форма была стабильной и поддерживаемой, придерживайтесь подхода: элементы не хранят данные сами по себе, они отображают реквизиты.

Типичные варианты привязки:

поле ввода привязано к реквизиту формы;

поле ввода привязано к реквизиту объекта (через реквизит формы, который связан с объектом);

таблица привязана к табличной части;

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

Что важно для промышленной разработки:

минимизируйте ручное заполнение визуальных элементов через Элементы.<Имя>.Значение = ..., если можно работать с реквизитами;

единообразно рассчитывайте значения: лучше один серверный метод, который возвращает структуру/таблицу, чем множество мелких вызовов.

Команды и безопасность: права, доступность, предсказуемость

Ранее мы обсуждали роли и права как часть архитектуры. В управляемых формах это проявляется напрямую.

Что нужно помнить

Видимость и доступность команды зависят от прав пользователя и логики формы.

Даже если кнопка скрыта, это не защита: защита должна быть на сервере.

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

Практический шаблон:

На клиенте определить, можно ли показывать команду (UI-удобство).

На сервере в самой операции сделать проверки (неизбежность правила).

Частые ошибки при разработке управляемых форм

Ошибка: «вся логика в обработчиках формы»

Последствия:

невозможно гарантировать правила при записи не из формы;

сложно тестировать и переиспользовать;

проблемы с клиент-серверной производительностью.

Как правильно:

бизнес-правила — в модуле объекта и серверных общих модулях;

форма — только управление UI и запуск команд.

Ошибка: «сервер на каждое ПриИзменении»

Последствия:

интерфейс тормозит;

сервер перегружен мелкими вызовами.

Как правильно:

вызывать сервер по явной команде;

группировать запросы;

использовать серверную подготовку данных при создании формы.

Ошибка: «элементы формы как хранилище состояния»

Последствия:

состояние теряется или ведет себя непредсказуемо;

сложнее сопровождать.

Как правильно:

хранить состояние в реквизитах формы;

элементы только отображают и позволяют ввод.

Мини-чеклист перед добавлением элемента или команды

Используйте этот чеклист, чтобы форма оставалась промышленно устойчивой:

Это данные, которые должны сохраняться? Если да — они должны быть в объекте или другом объекте данных.

Эта операция изменяет данные или учет? Если да — проверка должна быть на сервере.

Это событие будет срабатывать часто? Если да — избегайте серверных вызовов.

Можно ли сделать один «пакетный» серверный метод вместо нескольких мелких?

Где будет находиться команда в навигации (раздел, форма, командная панель) и кто должен ее видеть по правам?

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

Общие страницы платформы, где собраны технологические направления и документация (удобны как точки входа):

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

1C:Enterprise Development Tools

Что дальше по курсу

После понимания устройства управляемых форм логичный следующий шаг в практике:

собрать простой бизнес-сценарий (например, документ + движения + форма);

сделать формы списка и объекта с командами;

вынести расчеты и проверки на сервер;

проверить навигацию и права под разными пользователями.

Это закрепляет связку: метаданные → форма → события → клиент/сервер → устойчивые правила данных.

Запросы 1С и СКД: выборки, соединения, группировки и итоги

Связь с предыдущими темами курса

Ранее мы разобрали:

метаданные и объекты конфигурации (где живут данные: справочники, документы, регистры)

язык 1С и модули (где живет код)

событийную модель и клиент-серверное разделение (как и где код исполняется)

управляемые формы (как пользователь взаимодействует с данными)

Запросы и СКД связывают это в рабочую «промышленную» связку: как эффективно получать данные из информационной базы для форм, обработок и отчетов.

Ключевая идея темы:

Запрос 1С — инструмент точечной выборки и подготовки данных (в том числе для UI и бизнес-логики).

СКД (Система компоновки данных) — механизм построения отчетов и аналитики, который использует запросы как источники данных, но добавляет уровни: параметры, группировки, итоги, варианты, оформление.

!Общая картина: как запросы и СКД превращают данные конфигурации в формы и отчеты

Где в 1С применяются запросы и СКД

Запросы и СКД появляются почти в каждой прикладной задаче.

Формы списков и произвольные формы: отборы, подборы, расчеты, динамические списки.

Проведение документов: получение остатков, проверка доступности товара, подбор партий и т.д.

Обработки: массовые операции, сверки, переносы данных.

Отчеты: аналитика, управленческие и регламентированные отчеты.

Практическое правило клиент-серверной архитектуры:

запросы почти всегда выполняются на сервере, потому что это работа с данными

клиент получает уже подготовленный результат для отображения

Запрос 1С: базовые понятия и структура

Запрос — это объект встроенного языка Запрос, который содержит:

текст запроса на языке запросов 1С

параметры запроса (безопасный и быстрый способ фильтрации)

результат выполнения (РезультатЗапроса), который можно читать выборкой

Минимальный пример: выполнить запрос и прочитать выборку

Что здесь происходит:

ВЫБРАТЬ определяет поля результата

ИЗ определяет источник данных

ГДЕ задает отбор

УПОРЯДОЧИТЬ ПО сортирует

Выбрать() возвращает объект выборки, по которому можно идти Следующий()

Источники данных в запросах 1С

В языке запросов 1С источники данных описываются объектами метаданных.

Справочник.Номенклатура

Документ.РеализацияТоваров

РегистрНакопления.ТоварыНаСкладах

РегистрСведений.ЦеныНоменклатуры

Важно: разработчик мыслит не «таблицами SQL», а прикладными объектами.

Виртуальные таблицы регистров: зачем они нужны

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

для регистра накопления:

- Остатки — получить остатки на дату - Обороты — получить обороты за период

для регистра сведений:

- СрезПоследних — получить актуальное значение на дату

Эти таблицы важны промышленно, потому что:

они выражают задачу учета напрямую

обычно дают более корректный и быстрый путь, чем попытки «посчитать по документам»

Параметры запроса: правильная фильтрация и безопасность

Параметр — это значение, которое подставляется в запрос без конкатенации строк.

Пример: отбор по периоду и складу

Почему параметры — промышленная норма:

меньше ошибок в типах и форматах

проще читать запрос

меньше риск «сломать» запрос строковыми подстановками

проще повторно использовать один и тот же текст запроса

Соединения (JOIN): как собирать данные из нескольких источников

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

Основные типы соединений

| Тип соединения | Смысл | Когда использовать | |---|---|---| | ВНУТРЕННЕЕ СОЕДИНЕНИЕ | оставить только строки, где есть совпадение в обеих таблицах | когда отсутствие связи означает «строка не нужна» | | ЛЕВОЕ СОЕДИНЕНИЕ | оставить все строки слева, а справа подставить пустые значения при отсутствии совпадения | когда «справа может не быть данных», но строка все равно нужна |

!Интуитивное отличие внутреннего и левого соединения

Пример: продажи с подстановкой наименования номенклатуры

Практические замечания:

если вы уверены, что ссылка всегда заполнена и объект существует, можно рассматривать внутреннее соединение

если данные «могут отсутствовать» (например, необязательный реквизит), безопаснее левое

Группировки и агрегатные функции

Группировка нужна, когда бизнес хочет итог по разрезу: по клиентам, по складам, по номенклатуре.

Агрегатные функции

СУММА() — сумма по группе

КОЛИЧЕСТВО() — количество строк

МАКСИМУМ(), МИНИМУМ() — максимум/минимум

СРЕДНЕЕ() — среднее значение

Пример: обороты продаж по контрагентам за период

Что важно понимать:

в СГРУППИРОВАТЬ ПО перечисляются поля, по которым «склеиваются» строки

все остальные выбранные поля должны быть либо в группировке, либо под агрегатной функцией

Отбор по агрегатам: аналог HAVING

В 1С отбор по итогам группы делают через ИМЕЮЩИЕ.

Пример: показывать только контрагентов, у которых сумма продаж больше 100000.

Итоги в запросе: когда нужно «вместе с детализацией»

Иногда нужно получить и строки, и итоги (например, отчетная форма без СКД, либо подготовка данных для UI).

В языке запросов 1С есть оператор ИТОГИ, который позволяет получить итоговые строки по указанным разрезам.

Идея применения:

выводите детализацию

добавляете итоги по полю (например, по контрагенту)

результат читаете выборкой, учитывая, что там будут строки разных уровней

Важно: такой подход требует аккуратного чтения результата, и для типовых отчетов обычно удобнее СКД.

Временные таблицы (ПОМЕСТИТЬ): когда запрос становится сложнее

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

ПОМЕСТИТЬ сохраняет промежуточный результат во временную таблицу

следующий ВЫБРАТЬ может читать эту таблицу, не пересчитывая предыдущий шаг

Пример: сначала собрать продажи по номенклатуре, потом отсортировать и отфильтровать

Практический смысл:

проще читать и поддерживать

можно переиспользовать промежуточные результаты

часто меньше повторов в соединениях и группировках

Как выбирать: «чистый запрос» или СКД

Запрос и СКД не конкурируют, а дополняют друг друга.

Когда чаще нужен чистый запрос

нужно получить небольшой набор данных для формы или проверки

логика встроена в проведение/проверки документов

нужен точный контроль структуры результата

результат дальше обрабатывается кодом (например, заполняется табличная часть)

Когда чаще нужна СКД

нужен отчет с параметрами, вариантами, группировками, итогами

нужно дать пользователю настройки (отборы, группировки, поля)

нужно оформление, вывод в табличный документ, диаграммы

нужно единообразие отчетов в конфигурации

Короткое практическое правило:

если это отчет для пользователя — начинайте с СКД

если это сервисная выборка для алгоритма — начинайте с запроса

СКД (Система компоновки данных): что это и из чего состоит

СКД — механизм, который строит результат по схеме компоновки данных.

Основные элементы СКД

Наборы данных: обычно запросы (иногда несколько)

Поля:

- измерения (разрезы) - ресурсы (показатели, которые суммируются/агрегируются) - реквизиты (дополнительные поля)

Настройки компоновки:

- отборы - группировки - сортировки - параметры

Макет: как визуально выводить

Варианты отчета: разные представления для разных ролей/задач

Сильная сторона СКД: вы один раз задаете источники данных (запросы), а пользователь и аналитик могут «играть» настройками в рамках разрешенного.

Минимальный сценарий: запрос как набор данных СКД

Типовая архитектура отчета на СКД выглядит так:

запрос возвращает «плоскую» таблицу фактов (например, строки продаж)

СКД над этой таблицей делает группировки, итоги и отборы

Почему это удобно:

запрос отвечает за корректное получение фактов

СКД отвечает за представление и аналитику

Практика промышленного разделения: где должна жить логика

Чтобы отчет/форма были устойчивыми:

правила корректности данных должны быть обеспечены на сервере (объектами, регистрами, проверками)

запрос должен быть параметризованным и предсказуемым

СКД должна быть способом представить данные, а не «местом сложной бизнес-логики»

СКД допускает вычисляемые поля и выражения, но критичные проверки и правила лучше держать в серверных модулях и объектах.

Производительность запросов: минимальные правила, которые окупаются всегда

Выбирайте только нужные поля

Чем меньше полей и строк вы вытаскиваете, тем быстрее запрос и меньше нагрузка.

хорошо: выбрать Номенклатура, Количество, Сумма

плохо: выбрать десятки полей «на всякий случай»

Фильтруйте как можно раньше

Отбор в ГДЕ уменьшает объем данных, которые нужно соединять и группировать.

Используйте параметры вместо конкатенации

Параметры снижают риск ошибок и помогают СУБД и платформе корректно обрабатывать запрос.

Не подменяйте регистры документами

Если нужны остатки и обороты — используйте регистры и их виртуальные таблицы.

Следите за «раздуванием» строк в соединениях

Если соединяете таблицу фактов (строки документа) с таблицей, где может быть несколько записей на ключ (например, цены без отбора по виду цены и дате), вы получите умножение строк.

Практический прием:

сначала ограничьте правую таблицу (например, выбрать актуальную цену СрезПоследних), и только потом соединяйте

Помните про контексты: запросы на сервере

Запрос в обработчике формы должен вызываться серверным методом.

клиентская процедура: собрать параметры, вызвать сервер

серверная процедура: выполнить запрос, вернуть результат

Типичные ошибки и как их предотвращать

Ошибка: запросы из событий формы слишком часто

Если запрос выполняется на каждое ПриИзменении, UI начинает «тормозить».

Как исправлять:

делать пересчет по команде

группировать запросы в один серверный вызов

использовать подготовку данных в ПриСозданииНаСервере

Ошибка: отборы строкой вместо параметров

Это приводит к нечитабельным текстам запросов и ошибкам типов.

Как исправлять:

всегда использовать УстановитьПараметр()

Ошибка: попытка считать итоги «по документам»

Отчеты становятся тяжелыми и медленными.

Как исправлять:

переносить учетный итог в регистр

отчеты строить по регистрам и виртуальным таблицам

Что дальше по курсу

После запросов и СКД следующий практический шаг, который связывает все темы:

сделать документ с движениями в регистр

написать запросы для контроля и подбора (остатки, цены)

построить отчет на СКД по тем же данным

проверить клиент-серверную границу: UI вызывает сервер, сервер делает запрос и возвращает результат

Так формируется основа промышленной разработки: правильная модель данных → правильные движения → быстрые запросы → отчеты на СКД.

Отчеты и печатные формы: СКД, макеты, табличные документы

Связь с предыдущими темами курса

Ранее мы разобрали:

как проектировать данные через справочники, документы и регистры;

как писать код на встроенном языке и разделять его по клиенту и серверу;

как получать данные запросами и строить аналитику на СКД.

Следующий практический шаг в промышленной разработке — превратить данные и запросы в результат, который нужен пользователю:

отчеты (аналитика, итоговые таблицы, расшифровки);

печатные формы (акты, накладные, счета, внутренние бланки).

В 1С эти задачи чаще всего решаются связкой:

СКД для отчетов и аналитических таблиц;

макеты для шаблонов печати;

табличные документы как универсальный формат вывода и печати.

!Общая схема: как данные превращаются в отчет или печатную форму

Полезные официальные материалы общего уровня:

Платформа 1С:Предприятие 8

Технологии платформы 1С:Предприятие

Термины: отчет, печатная форма, табличный документ, макет

Чтобы дальше не путаться, зафиксируем понятия.

Отчет

Отчет — это объект конфигурации, цель которого показать пользователю данные для анализа. У отчета обычно есть:

параметры (период, организация, склад, контрагент);

варианты и настройки (группировки, отборы, показатели);

вывод в табличный документ.

Отчет часто подразумевает интерактивность:

пользователь может менять настройки;

доступны расшифровки;

возможны разные варианты (для разных ролей).

Печатная форма

Печатная форма — это представление данных документа или другого объекта в виде оформленного бланка. Типовые свойства:

фиксированная структура (шапка, табличная часть, подписи);

ориентация на печать и выгрузку (например, в PDF);

предсказуемый результат (важно для бухгалтерии и внешних контрагентов).

Табличный документ

Табличный документ — это формат вывода в 1С, похожий на электронную таблицу:

строки, колонки, ячейки;

объединения, рамки, шрифты, выравнивания;

удобен для печати и экспорта.

Практический смысл: и отчеты на СКД, и печатные формы чаще всего в итоге формируют именно ТабличныйДокумент.

Макет

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

Промышленная идея: логика подготовки данных — в коде, оформление — в макете.

Отчеты на СКД: зачем они нужны и как устроены

СКД (Система компоновки данных) — стандартный механизм платформы для построения отчетов.

Когда выбирать СКД

СКД подходит, когда:

нужен отчет для пользователя с параметрами и настройками;

нужна группировка и итоги по разрезам;

нужно несколько вариантов отчета;

важно единообразие отчетов в конфигурации.

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

Из чего состоит отчет на СКД

На уровне модели удобно мыслить так:

Наборы данных — обычно запросы, которые возвращают «плоские факты».

Поля — то, что можно вывести:

1. измерения (разрезы для группировок); 2. ресурсы (показатели, которые суммируются); 3. реквизиты (дополнительные поля).

Настройки компоновки:

1. параметры; 2. отборы; 3. группировки; 4. сортировки; 5. итоги.

Макет вывода — оформление результата.

Варианты — преднастроенные наборы настроек.

Практический принцип: запрос отвечает за корректные факты, а СКД — за представление и агрегацию.

Проектирование отчета на СКД: промышленный алгоритм

Ниже — типовой маршрут, который помогает не «накрутить» отчет, а спроектировать его устойчиво.

Определить цель и границы отчета

Зафиксируйте:

вопрос бизнеса (что пользователь хочет понять);

период, организацию, разрезы;

что считается показателем (сумма, количество, маржа);

допустимую детализацию (до документа, до строки документа, до номенклатуры).

Промышленный эффект: вы заранее контролируете объем данных и производительность.

Выбрать правильный источник данных

Обычно:

для остатков и оборотов — регистры накопления и их виртуальные таблицы;

для актуальных значений на дату — регистры сведений и СрезПоследних;

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

Правило из предыдущей темы курса: итоги по документам почти всегда хуже, чем итоги по регистрам.

Сделать запрос «плоских фактов»

Идеальный запрос для СКД:

возвращает строки фактов (например, продажи по номенклатуре);

содержит только нужные поля;

параметризован (период, организация, склад);

не содержит лишней «косметической» логики.

Вынести параметры в явный контракт

Параметры отчета должны быть понятны:

ДатаНач, ДатаКон;

Организация;

Склад (если применимо).

Промышленная привычка: не полагаться на «магические» значения из формы; параметр — это контракт между UI и сервером.

Выполнение отчета: где выполняется логика

Важное соединение с темами про клиент-сервер.

пользователь меняет параметры на форме отчета (клиент);

отчет выполняет запросы и компоновку (сервер);

результат возвращается как ТабличныйДокумент и показывается пользователю (клиент).

Минимальный пример: сформировать табличный документ на сервере

Ниже пример схемы кода (не привязан к конкретному отчету), показывающий архитектурный принцип: формирование на сервере, показ на клиенте.

Ключевая мысль:

команда и показ — на клиенте;

данные и компоновка — на сервере.

Печатные формы: что отличается от отчета

Печатная форма выглядит похоже (тоже табличный документ), но отличается по смыслу.

Отличия печатной формы от отчета

| Признак | Отчет | Печатная форма | |---|---|---| | Цель | анализ, сравнение, итоги | оформить бланк документа | | Изменяемость пользователем | часто много настроек | чаще фиксированный формат | | Источник | регистры, документы, любые наборы данных | обычно один документ и его строки | | Требования к стабильности | важно, но допускаются варианты | очень важно, чтобы «всегда одинаково» |

Промышленный вывод: печатная форма должна быть максимально предсказуемой и не зависеть от UI-сценария.

Макеты печатных форм: как устроен шаблон

Чаще всего печатную форму делают через:

макет табличного документа с областями;

код, который:

- получает макет; - заполняет параметры областей; - выводит области в ТабличныйДокумент.

Области макета

В макете удобно выделять области:

Шапка (организация, контрагент, номер, дата);

Строка (одна строка табличной части);

Итоги (итог по количеству/сумме);

Подписи.

!Визуально: как шаблон печати делится на области

Почему области — промышленная практика

Потому что:

вы отделяете оформление от логики;

меняется макет — не обязательно менять код;

код становится линейным и читаемым.

Формирование печатной формы: базовый шаблон кода

Ниже — типовой подход: сервер формирует ТабличныйДокумент по макету.

Пример: вывести шапку и строки табличной части

Что важно понять в этом фрагменте:

ПолучитьМакет("ПечатнаяФорма") берет шаблон оформления;

ПолучитьОбласть("Шапка") и ПолучитьОбласть("Строка") берут «куски» шаблона;

Параметры.Вставить() заполняет значения для подстановки;

ТабДок.Вывести() добавляет область в итоговый табличный документ.

Где показывать печатную форму

Показ — это UI, значит чаще на клиенте.

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

Где должна жить логика печати

Чтобы печать была промышленно надежной, разделяйте ответственность.

Что допустимо считать в печати

Допустимо:

форматирование представлений;

вычисление итогов по уже готовым данным документа;

подстановка текстов и реквизитов.

Что нельзя делать как «скрытую логику печати»

Нежелательно:

тянуть в печать бизнес-правила (например, пересчет скидки, подбор цен);

делать множественные обращения к базе в циклах по строкам;

менять данные документа во время формирования печати.

Практический принцип:

учет и правила должны быть обеспечены документом и регистрами;

печать должна отображать уже корректный факт.

Производительность: как не сделать «медленный отчет» и «тормозную печать»

Эта тема напрямую продолжает статью про запросы.

Правила, которые окупаются всегда

Один запрос вместо множества

1. Плохо: в цикле по строкам документа для каждой строки запрашивать цену или остаток. 2. Хорошо: одним запросом получить все цены для списка номенклатуры.

Параметры вместо конкатенации

1. Параметры проще поддерживать и безопаснее.

Выбирать только нужные поля

1. В отчете и печати не вытаскивайте «все реквизиты справочника», если выводите 2 поля.

Разделять подготовку данных и вывод

1. Сначала собрать структуру данных (таблица значений, структура параметров). 2. Потом вывести в табличный документ.

Типичная оптимизация печатной формы

Если печать требует дополнительных данных (например, единицы измерения, артикул), промышленный подход:

собрать список номенклатуры из табличной части документа;

одним запросом получить нужные поля;

заполнить соответствие Номенклатура → данные;

в цикле выводить строки, доставая данные из соответствия, а не из базы.

Качество и сопровождение: что важно в реальных проектах

Стабильность результата

Для печатных форм полезно договориться внутри команды:

где хранятся макеты;

как называются области и параметры;

как обеспечивается обратная совместимость (если макет меняется).

Минимальная «контрактность» макета

Практика, которая снижает хаос:

в комментарии к макету или в коде фиксировать список областей и параметров;

проверять наличие областей при разработке (иначе пользователь увидит ошибку «не найдена область» уже в эксплуатации).

Клиент-серверное разделение

Поддерживайте правило из прошлых тем:

UI-команды и навигация — клиент;

запросы и сбор данных — сервер;

формирование табличного документа — обычно сервер;

показ и печать — клиент.

Что дальше по курсу

Эта тема завершает базовую «линию данных»: регистры → запросы → СКД/макеты → табличный документ.

Дальше логично переходить к практике промышленной разработки вокруг этих механизмов:

стандартизация общих модулей (сервисный слой для отчетов и печати);

переиспользование запросов и параметров;

права доступа на отчеты и печатные формы;

тестирование и контроль изменений (чтобы новый релиз не сломал печать и отчеты).