Мастер 1С:Предприятие — от основ до профессиональной разработки

Архитектура 1С и основы работы в Конфигураторе

Эта статья открывает курс и закладывает базу: как устроена 1С:Предприятие, что такое информационная база и конфигурация, и как разработчик работает с ними в Конфигураторе. Если вы поймёте эту архитектуру сейчас, дальше (справочники, документы, регистры, формы, запросы, обмены) будет складываться в единую систему.

Что такое 1С:Предприятие

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

платформа даёт готовую инфраструктуру (хранилище данных, формы, права, отчёты, механизмы клиент-серверной работы)

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

Ориентиры для чтения о платформе:

1С:Предприятие — Википедия

Платформа 1С:Предприятие 8 (официальный сайт)

Ключевые понятия: информационная база и конфигурация

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

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

Данные: элементы справочников, проведённые документы, записи регистров, настройки пользователей

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

Конфигурация и конфигурация базы данных

В 1С важно различать два состояния конфигурации:

Конфигурация — то, что вы редактируете в Конфигураторе (исходное описание метаданных и кода)

Конфигурация базы данных — то, по чему реально работает режим 1С:Предприятие (то, что применено к базе)

Пока вы не выполните обновление, изменения “в конфигураторе” не попадут в работу пользователей.

Общая архитектура 1С

Режимы работы: Конфигуратор и 1С:Предприятие

В одной и той же ИБ есть два основных режима запуска.

| Режим | Для кого | Что делают | Результат | |---|---|---|---| | Конфигуратор | разработчик, администратор | меняют метаданные, пишут код, обновляют конфигурацию базы данных | меняется структура/логика системы | | 1С:Предприятие | пользователь, тестировщик, разработчик | вводят данные, работают с формами, выполняют бизнес-процессы | меняются данные и состояние учёта |

Практическое правило: разработка — в Конфигураторе, проверка поведения — в 1С:Предприятии.

Варианты хранения: файловая и клиент-серверная ИБ

Информационная база может быть организована по-разному.

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

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

Важно для разработчика:

в файловой базе проще стартовать, но сложнее обеспечивать надёжность и конкурентную работу при росте

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

!Общая клиент-серверная схема работы 1С

Метаданные: из чего строится прикладное решение

Метаданные — это “конструктор” вашей системы: вы не создаёте таблицы вручную, а описываете объекты предметной области, а платформа сама создаёт структуру хранения и интерфейсы (частично автоматически, частично через формы).

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

Ниже — минимальный словарь, чтобы уверенно ориентироваться в дереве конфигурации.

Справочники: постоянные сущности (контрагенты, номенклатура, сотрудники)

Документы: события, меняющие состояние учёта (поступление, реализация, начисление зарплаты)

Регистры:

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

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

Отчёты и Обработки:

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

Планы видов характеристик и планы счетов: специализированные объекты для расширяемых свойств и бухучёта

Общие объекты и “склейка” приложения

Кроме предметных объектов есть инфраструктурные.

Общие модули: код, который используется из разных мест

Роли и права: кто что может видеть и делать

Подсистемы: логическая группировка функциональности (влияет на навигацию и структуру интерфейса)

Общие формы, командный интерфейс, общие команды: построение пользовательского взаимодействия

!Упрощённая карта дерева метаданных и связей

Модули и встроенный язык

Логика в 1С пишется во встроенном языке (часто говорят BSL). Код распределяется по модулям, которые привязаны к объектам и контекстам выполнения.

Где живёт код

Самые часто встречающиеся места:

Модуль объекта (например документа): логика самого объекта, обработчики проведения, заполнения

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

Общие модули: общая логика, утилиты, слои приложения

Клиент и сервер: почему это важно с самого начала

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

Типовая логика разделения:

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

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

Мини-пример, показывающий идею разделения (упрощённо):

Здесь важно понимать термины:

&НаКлиенте и &НаСервере — указания, где выполняется код

Экспорт — означает, что функцию можно вызвать из других модулей (например, из клиентского кода)

Базовый рабочий цикл разработчика в Конфигураторе

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

Открыть ИБ в Конфигураторе.

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

Написать или поправить код (модуль объекта, формы, общий модуль).

Выполнить Обновить конфигурацию базы данных.

Запустить ИБ в режиме 1С:Предприятие и проверить поведение.

При необходимости повторить цикл.

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

На что обратить внимание с первого дня

Резервные копии

Перед любыми серьёзными изменениями держите привычку делать бэкап ИБ (особенно для файловой базы). Это дисциплина, которая экономит часы и дни.

Разделяйте “данные” и “структуру”

Запомните два вопроса, которые помогут быстро диагностировать проблемы:

“Я поменял метаданные, но в предприятии ничего не изменилось” — чаще всего забыто обновление конфигурации базы данных.

“Данные пропали/не те” — это уже про работу пользователей, загрузки, проведение, права, транзакции.

Типовые конфигурации и доработка

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

Итоги

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

1С состоит из платформы и прикладной конфигурации

в ИБ есть данные и конфигурация базы данных

разработка ведётся в Конфигураторе, работа пользователей — в 1С:Предприятии

решение строится из метаданных (справочники, документы, регистры и т.д.)

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

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

Объекты конфигурации: справочники, документы, регистры, отчеты

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

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

!Поток данных: справочники задают сущности, документы фиксируют события, регистры накапливают итоги, отчеты анализируют

Как выбрать объект под задачу

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

| Объект | Что описывает | Что хранит | Когда использовать | |---|---|---|---| | Справочник | Сущность предметной области | Карточки объектов: реквизиты, связи | Номенклатура, контрагенты, склады, сотрудники | | Документ | Событие или операция | Данные операции, табличные части | Поступление, реализация, перемещение, начисление | | Регистр | Факты, итоги, состояние | Записи по правилам регистра | Остатки, обороты, цены, курсы, статусы | | Отчет | Представление информации | Обычно ничего не хранит, а вычисляет | Остатки, продажи, сверки, аналитика |

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

Справочники

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

Примеры:

номенклатура

контрагенты

организации

склады

Структура справочника

Справочник состоит из элементов, у каждого элемента есть:

Ссылка: системный идентификатор элемента (на него обычно ссылаются документы и регистры)

Код: удобный идентификатор для людей или интеграций (настройка зависит от задачи)

Наименование: человекочитаемое имя

Реквизиты: дополнительные поля (например, артикул, ставка НДС, телефон)

Дополнительно могут встречаться:

Иерархия: группы и элементы (для номенклатуры, статей затрат)

Владельцы: подчиненные справочники (например, банковские счета, привязанные к контрагенту)

Табличные части: если у карточки есть повторяющиеся строки (например, несколько контактных лиц)

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

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

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

не пытайтесь хранить в справочнике итоги и остатки: это задача регистров

Документы

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

Примеры:

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

реализация товаров

перемещение между складами

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

Типичный документ содержит:

Реквизиты шапки: дата, организация, контрагент, склад, ответственное лицо

Табличные части: строки операции (например, список товаров с количеством и ценой)

Проведение: механизм отражения документа в регистрах

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

Проведение документа это действие, при котором документ:

проверяет корректность данных

формирует движения по регистрам

записывает эти движения

Термины:

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

Набор записей: объект в коде, через который создают и записывают строки регистра

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

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

Ниже пример логики проведения: по табличной части Товары формируются движения прихода в регистр накопления ОстаткиТоваров.

Что здесь важно понять:

ОбработкаПроведения это стандартная процедура модуля объекта документа, где описывают проведение

Движения.<ИмяРегистра> это доступ к наборам записей регистров, связанных с документом

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

Регистры

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

Если упростить:

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

регистр отвечает на вопрос что теперь в учете или какие факты накоплены

Основные виды регистров

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

Регистр сведений: хранит факты и состояния (цены, статусы, настройки), часто с привязкой ко времени

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

Из чего состоит регистр

У регистров обычно есть три типа полей.

Измерения: по чему мы группируем учет (например, номенклатура, склад)

Ресурсы: что суммируем или накапливаем (например, количество, сумма)

Реквизиты: дополнительные поля записи, которые не участвуют в суммировании как ресурс (например, комментарий, источник)

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

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

если вы хотите складывать значения, это почти всегда ресурс

Регистр накопления: как это выглядит по смыслу

Пример модели для учета товаров:

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

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

ресурс: Количество

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

Почему отчеты любят регистры

Потому что регистр спроектирован для ответа на типовые вопросы:

сколько товара осталось на каждом складе на конкретную дату

какие были обороты за период

какое значение параметра было актуально на дату

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

сложно правильно учитывать отмену проведения и перепроведение

сложно получать состояние на дату без пересчета всей истории

медленно на больших объемах

Отчеты

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

Отчет чаще всего:

не хранит данные

выполняет запросы к регистрам и справочникам

формирует результат для анализа

Два базовых подхода к отчетам

через Систему компоновки данных: чаще всего основной инструмент в прикладной разработке

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

Мини-пример запроса остатков на дату

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

Пояснения к ключевым элементам:

Остатки(&НаДату) это виртуальная таблица регистра накопления, которая возвращает остатки на указанную дату

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

&НаДату это параметр запроса, который задается через УстановитьПараметр

Связь объектов в реальной задаче

Рассмотрим типовой сценарий учета товара.

В справочнике Номенклатура хранятся карточки товаров.

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

При проведении документ пишет движения в регистр накопления ОстаткиТоваров.

Отчет ОстаткиТоваровНаСкладах читает остатки из регистра и показывает результат.

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

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

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

Частые ошибки начинающих

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

делают справочник там, где нужна таблица движений, и наоборот

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

строят ключевые отчеты по документам, хотя задача решается регистром в разы проще

Итоги

Вы разобрали базовые строительные блоки конфигурации:

справочники хранят долгоживущие сущности

документы фиксируют события и при проведении формируют движения

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

отчеты читают данные (чаще из регистров) и показывают пользователю

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

Язык 1С: модули, события, формы и управляемый интерфейс

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

Цель этой темы: научиться уверенно отвечать на четыре вопроса.

Где писать код для конкретной задачи

Какое событие сработает и когда

Как устроена форма и её модуль

Как пользователю показывается функциональность через управляемый интерфейс

!Карта: как метаданные связываются с модулями, формами и действиями пользователя

Встроенный язык 1С и контексты выполнения

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

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

Клиент: интерфейс, реакции на действия пользователя, работа с элементами формы

Сервер: чтение и запись данных, проведение, запросы, транзакции, контроль целостности

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

&НаКлиенте

&НаСервере

&НаСервереБезКонтекста

Практический смысл:

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

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

Модули: где живёт код и зачем их так много

Модуль в 1С это место, где хранится код, привязанный к объекту метаданных или к уровню приложения.

Основные модули прикладного решения

| Модуль | К чему привязан | Для чего используют чаще всего | |---|---|---| | Модуль объекта | к конкретному объекту (элемент справочника, документ) | проверка перед записью, проведение, расчёты реквизитов, служебные процедуры объекта | | Модуль менеджера | к типу объекта (например, к справочнику как к классу) | фабричные методы, подборы, общая логика для всех объектов этого типа | | Модуль формы | к форме (управляемой) | обработчики команд, реакция на изменение полей, управление интерфейсом | | Общий модуль | независим от конкретного объекта | переиспользуемые функции, сервисы, слой бизнес-логики | | Модуль команды | к общей команде или команде объекта | логика выполнения команды, если её удобнее вынести из формы |

Важно не заучить весь список, а понять принцип.

если логика относится к конкретной записи (например, к документу как к объекту) это модуль объекта

если логика относится к типу в целом (например, “создать документ по шаблону”) это модуль менеджера или общий модуль

если логика относится к конкретному экрану это модуль формы

Экспорт и границы доступности

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

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

Общие модули как основа “слоёв” приложения

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

общий модуль “Сервис” для работы с датами, строками, форматированием

общий модуль “БизнесЛогика” для расчётов, проверок, правил проведения

общий модуль “Интеграция” для обменов и загрузок

Если вы начнёте складывать всё в модули форм, приложение станет “формоцентричным”: его будет сложно тестировать, переиспользовать и развивать.

События: что запускает код

Событие это момент жизненного цикла объекта или формы, когда платформа вызывает ваш обработчик.

В 1С удобно мыслить так.

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

платформа вызывает обработчик события

вы либо разрешаете действие, либо запрещаете, либо дополняете стандартное поведение

События объекта и события формы

Условно события делятся на две группы.

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

События формы: открытие, изменение полей, нажатие кнопок, команды

Главная граница ответственности:

объектные события защищают данные и правила учёта

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

Типовой жизненный цикл документа

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

Пользователь открывает форму документа.

Форма создаётся и заполняется начальными значениями.

Пользователь меняет поля.

Пользователь нажимает “Записать”.

Платформа вызывает проверки и записывает объект.

Пользователь нажимает “Провести”.

Платформа формирует движения и записывает их в регистры.

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

Обработчики, которые встречаются чаще всего

Чтобы не тонуть в списках, держите “ядро”, которое нужно на старте.

ПередЗаписью в модуле объекта: финальные проверки и подготовка данных перед записью

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

ОбработкаПроведения в модуле объекта документа: формирование движений

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

Пример проверки перед записью.

Что важно понимать:

Отказ = Истина прекращает стандартное действие

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

Управляемые формы: структура и принципы работы

В управляемом приложении пользователь работает через управляемые формы. Форма это не просто “экран”, а связка.

Реквизиты формы: данные, которые форма хранит для работы

Элементы формы: поля, таблицы, кнопки, группы

Команды: действия (например, “Заполнить”, “Рассчитать”, “Печать”)

Модуль формы: код, который реагирует на события формы и вызывает серверную логику

Реквизиты формы и реквизиты объекта

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

Реквизит объекта хранится в базе (если объект записан)

Реквизит формы нужен форме для работы сценария и может не храниться в базе

Пример: “Период отчёта” в форме отчёта это реквизит формы, а “Контрагент” в справочнике это реквизит объекта.

Клиентский обработчик и серверная функция: типовой шаблон

Одна из самых полезных привычек: на клиенте только инициировать действие и показать результат, а расчёт и данные получать с сервера.

Что закрепляем:

интерфейсная часть находится на клиенте

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

Типичные ошибки при работе с формами

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

“бизнес-логика” внутри формы, из-за чего её невозможно переиспользовать

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

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

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

Ключевые элементы.

Подсистемы: логические разделы функциональности, которые формируют структуру разделов

Команды: действия, которые можно разместить в интерфейсе

Командный интерфейс: настройка того, что видно в разделах, панелях действий и навигации

Роли и права: ограничивают, что пользователь может открывать и выполнять

Подсистемы как “каркас” приложения

Подсистема это способ сгруппировать объекты и команды так, чтобы пользователь не видел “всё сразу”. Обычно подсистемы соответствуют областям бизнеса.

продажи

закупки

склад

финансы

администрирование

Если объект не включён в подсистему и не имеет команд в интерфейсе, пользователь может просто не найти его, даже если он существует.

Команды: единый способ запускать действия

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

к форме (кнопка на форме)

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

к подсистеме (общая команда раздела)

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

Роли и права: минимальная связка, которую нужно понимать

Права в 1С обычно настраиваются через роли.

роль описывает набор разрешений

пользователю назначаются роли

интерфейс автоматически “режется” в зависимости от прав

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

документ не включён в подсистему или командный интерфейс

у пользователя нет прав на чтение/просмотр

Как связать всё с объектами из прошлой темы

Возьмём цепочку из предыдущей статьи: справочник, документ, регистр, отчёт.

справочник задаёт сущности, а код в модуле объекта может проверять корректность реквизитов перед записью

документ фиксирует событие, а код в ОбработкаПроведения пишет движения в регистры

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

отчёт показывает результат, а форма отчёта управляет параметрами и выводом

Эта связь важнее любых “приёмов”: мастерство в 1С начинается там, где вы чётко понимаете, какой слой за что отвечает.

Итоги

В этой теме вы собрали рабочую модель разработки на языке 1С.

код в 1С организован по модулям, привязанным к объектам и формам

поведение системы задаётся через события объекта и формы

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

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

разделение клиентского и серверного кода это не формальность, а основа надёжности и производительности

Запросы и работа с данными: СКД, оптимизация, транзакции

В прошлых темах мы разобрали, из чего состоит конфигурация (справочники, документы, регистры, отчёты) и где живёт код (модули, события, формы, клиент/сервер). Теперь соберём это в практическую основу профессиональной разработки: как правильно получать данные запросами, как строить отчёты через СКД (Система компоновки данных), как думать про производительность, и как безопасно изменять данные через транзакции.

!Как запросы и СКД связывают интерфейс, серверный код и хранилище данных

Что такое запрос в 1С и зачем он нужен

Запрос в 1С — это способ получить данные из информационной базы на сервере, используя язык запросов 1С (по смыслу близок к SQL, но ориентирован на объекты 1С: справочники, документы, регистры, виртуальные таблицы).

Запрос используют, когда нужно:

получить выборку данных по условиям

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

быстро получить итоги по регистрам (остатки, обороты)

подготовить данные для отчёта, обработки, проверки проведения

Ключевая привычка разработчика: всё, что можно “достать” одним запросом, обычно лучше доставать запросом, чем циклами по объектам.

Базовая структура запроса в BSL

Минимальный рабочий шаблон состоит из:

объекта Запрос

текста запроса Запрос.Текст

параметров УстановитьПараметр

выполнения Выполнить()

получения результата через Выбрать() или Выгрузить()

Пример: получить список номенклатуры по группе.

Почему параметры важнее, чем “склейка строк”

Параметр &Группа нужен не только для удобства.

это безопаснее, чем формировать текст запроса конкатенацией строк

сервер может лучше кешировать и оптимизировать выполнение запросов с параметрами

код проще читать и сопровождать

Результат запроса: Выбрать() и Выгрузить()

В 1С два частых сценария работы с результатом.

Выбрать() возвращает выборку, по которой вы проходите циклом (подходит для потоковой обработки)

Выгрузить() сразу делает ТаблицаЗначений (удобно для передачи на клиент или в табличный документ)

Пример с Выбрать():

Регистры и виртуальные таблицы: быстрый путь к итогам

В прошлой теме про регистры мы говорили: состояние учёта берут из регистров. На уровне запросов это выражается тем, что вы очень часто обращаетесь не к “сырым движениям”, а к виртуальным таблицам.

Примеры виртуальных таблиц регистра накопления:

Остатки(&НаДату) — остатки на дату

Обороты(&Нач, &Кон) — обороты за период

Пример: остатки товаров на складе.

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

СКД: Система компоновки данных как стандарт отчётности

СКД (Система компоновки данных) — это механизм 1С для построения отчётов, где вы описываете:

наборы данных (запросы и источники)

поля, ресурсы, группировки

параметры

варианты настроек

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

СКД особенно ценна тем, что позволяет:

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

добавлять варианты отчёта (разные группировки и отборы)

унифицировать подход к отчётам в конфигурации

Типовая “анатомия” отчёта на СКД

В отчёте со СКД обычно есть три слоя.

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

Настройки компоновки: вариант отчёта (как группировать, что выводить, какие отборы применить).

Форма отчёта: интерфейс, где пользователь задаёт параметры и нажимает “Сформировать”.

Где появляется код, если СКД “и так всё умеет”

Код нужен, когда вы хотите:

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

подменить настройки варианта

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

сделать “обвязку” вокруг формирования (проверки прав, подготовка временных данных)

Мини-шаблон установки параметров СКД в форме отчёта (идея, названия объектов формы зависят от конкретной формы):

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

Когда лучше СКД, а когда лучше “запрос + код”

| Подход | Сильные стороны | Когда выбирать | |---|---|---| | СКД | настраиваемость пользователем, стандартная отчётность, быстрый старт | большинство управленческих и регламентированных отчётов | | Запрос + код | полный контроль формата и логики, нестандартные вычисления | сложные печатные формы, специфические выгрузки, нестандартные алгоритмы |

Важно: даже если отчёт делается “запрос + код”, сами данные почти всегда рационально получать запросом, а не чтением объектов в цикле.

Оптимизация запросов: как мыслит разработчик “на больших данных”

Оптимизация в 1С почти всегда начинается с простого вопроса: что именно делает запрос, сколько строк он читает, и можно ли прочитать меньше.

Правила, которые дают эффект чаще всего

Выбирайте только нужные поля: не делайте ВЫБРАТЬ * по привычке.

Фильтруйте как можно раньше: условия в ГДЕ уменьшают объём обрабатываемых данных.

Используйте параметры: это упрощает повторное выполнение и уменьшает риск ошибок.

Опирайтесь на регистры и их виртуальные таблицы: остатки и обороты берите через Остатки() и Обороты().

Не переносите расчёты в клиент: тяжелые запросы должны выполняться на сервере.

Осторожно с функциями в условиях: условие вида “преобразуй поле и сравни” часто мешает эффективной обработке.

Частая ошибка: “вытащим всё и отфильтруем в цикле”

Антипаттерн:

запрос возвращает десятки тысяч строк “на всякий случай”

дальше на сервере или, хуже, на клиенте идёт фильтрация в цикле

Правильнее:

уточнить ГДЕ

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

использовать виртуальные таблицы регистров

Временные таблицы: когда они полезны

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

сложный запрос состоит из нескольких этапов

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

нужно повысить читаемость сложной логики

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

Транзакции: как безопасно изменять данные

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

Это нужно, когда вы делаете несколько связанных изменений:

создаёте документ и сразу создаёте связанные записи

выполняете групповую обработку (много объектов)

выполняете обмен, где нельзя оставить “половину записанного”

Для общего понимания термина можно ориентироваться на определение транзакции в информатике: Транзакция (информатика)).

Базовые команды транзакций в 1С

В серверном коде чаще всего используются:

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

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

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

Типовой безопасный шаблон (важно: делать откат в обработке исключения):

Где транзакции особенно важны

при массовых изменениях, чтобы не оставить базу “в полусостоянии”

при сложных алгоритмах проведения, где делаются дополнительные записи

в интеграциях, где один пакет данных должен быть применён целиком

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

Транзакции — это про запись в базу, значит:

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

на клиенте транзакцию “держать” нельзя: клиент должен только инициировать действие и показать результат

!Шаблон выполнения транзакции с фиксацией или откатом

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

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

Форма (клиент): собирает параметры (период, организация, склад), вызывает сервер.

Общий модуль или модуль объекта (сервер): выполняет запросы, проверяет правила, при необходимости управляет транзакцией.

Регистры: основной источник итогов для отчётов и контрольных проверок.

СКД: стандартный путь построить отчёт, который пользователь сможет настраивать.

Если вы удерживаете границы ответственности (клиент — интерфейс, сервер — данные и целостность), то и производительность, и надёжность становятся управляемыми.

Итоги

Запрос — основной инструмент чтения и агрегирования данных в 1С.

Параметры запроса — стандарт безопасной и сопровождаемой разработки.

Виртуальные таблицы регистров (остатки/обороты) — самый частый путь к правильным итогам.

СКД — стандартная система отчётности, где метаданные и настройки часто важнее кода.

Оптимизация начинается с сокращения объёма читаемых данных и правильного выбора источника (регистры, виртуальные таблицы).

Транзакции защищают целостность: либо записали всё, либо откатили всё.

Для справки по платформе: Платформа 1С:Предприятие 8 (официальный сайт)

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

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

данные не попадают в 1С из внешних систем и не уходят обратно

пользователи видят лишнее или не могут сделать нужное

обновление типовой конфигурации ломает доработки

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

Цель статьи: дать практическую картину как это делают в проектах и какие механизмы платформы использовать.

!Карта типовых каналов интеграции вокруг 1С

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

Интеграция в 1С обычно решает одну из задач:

синхронизация справочников и документов между двумя 1С

обмен с внешними системами по HTTP

пакетная загрузка из файлов

публикация данных для отчётности и витрин

Базовые подходы к обменам

| Подход | Когда подходит | Сильные стороны | Риски и ограничения | |---|---|---|---| | Планы обмена | 1С ↔ 1С, распределённые базы | встроенный механизм, поддержка регистрации изменений | требует дисциплины настройки узлов и правил | | HTTP-сервисы и HTTP-запросы | интеграция с сайтом, CRM, микросервисами | гибкость, современный сценарий, удобен для near-real-time | нужно продумать авторизацию, идемпотентность, логи | | Web-сервисы (SOAP) | интеграция с корпоративными системами, где принят SOAP | формализованный контракт | часто тяжелее в сопровождении | | Файловый обмен (CSV, XLSX, XML) | разовые загрузки, миграции, ручной обмен | проще стартовать | больше ручных ошибок, сложнее контролировать целостность |

С точки зрения архитектуры из прошлых статей:

клиентские формы лишь запускают обмен и показывают статус

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

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

Планы обмена

План обмена в 1С чаще всего используется для сценариев 1С ↔ 1С, когда нужно:

хранить узлы обмена

регистрировать изменения объектов

формировать сообщения обмена и применять их

Ключевые понятия:

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

регистрация изменений: отметка, что объект изменён и должен уйти в обмен

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

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

HTTP-интеграции

HTTP-интеграции в 1С обычно делятся на две роли.

1С выступает сервером и принимает запросы через HTTP-сервис

1С выступает клиентом и сама вызывает внешние API через HTTP-запрос

Типовые правила проектирования:

делайте контракт версионируемым (например, /api/v1/...)

все входящие данные валидируйте на сервере

продумывайте повторную обработку запроса без дублей

Мини-скелет HTTP-сервиса (идея, обработчик зависит от настроек конкретного сервиса):

Идемпотентность и защита от дублей

В интеграциях часто приходит один и тот же документ повторно: из-за повторной отправки, таймаута, сетевого сбоя.

Хорошая практика:

добавлять внешний идентификатор (например, ExternalID) в документ или регистр сведений

при приёме данных сначала искать, не создан ли документ ранее

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

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

измерения: Источник, ТипОбъекта, ExternalID

ресурс или реквизит: СсылкаНаОбъект

Очереди и фоновые задания

Если обмен тяжёлый и не должен “держать” пользователя, используйте:

регламентные задания: периодический запуск

фоновые задания: разовая обработка в фоне

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

Права доступа и безопасность

Модель безопасности в 1С строится вокруг связки:

пользователи

роли

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

Важно различать два уровня.

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

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

!Как роли дают права и как RLS сужает данные

Роли

Роль обычно включает:

права на чтение, добавление, изменение, удаление

права на проведение, просмотр движений, интерактивные команды

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

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

начинайте с минимально нужных прав

делайте отдельные роли “просмотр” и “ввод”

не раздавайте широкие роли из удобства, иначе аудит и поддержка станут сложнее

Ограничение доступа к данным

Ограничение доступа к данным часто называют RLS по аналогии с Row Level Security.

Его смысл:

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

Примеры условий:

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

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

управленческие отчёты только по подразделению

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

Типовые ошибки в правах

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

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

делать одну роль “Администратор” для всех “чтобы не мешать работать”

Обновления конфигурации и сопровождение типовых

В реальных проектах вы часто дорабатываете типовую конфигурацию. Это означает постоянный конфликт интересов:

бизнес хочет новые возможности и обновления законодательства

разработка добавляет свои объекты, формы и логику

обновление поставщика может затронуть ваши изменения

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

Полезно держать в голове различие:

конфигурация поставщика: то, что приходит в обновлениях

ваши изменения: то, что добавили или поменяли вы

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

Расширения конфигурации

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

Когда расширения особенно полезны:

дополнительные реквизиты, формы, команды

переопределение обработчиков и логики без прямой правки типовых объектов

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

Ограничение подхода: не всё можно сделать расширением, и при сложной переработке бизнес-логики иногда без изменения основной конфигурации не обойтись.

Процесс обновления как проектная дисциплина

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

обновление выполняется на тестовой копии

запускаются сценарии проверки и регресс

фиксируются конфликты и план их разрешения

обновление переносится в продуктив в согласованное окно

проверяются ключевые процессы и отчёты

!Типовой конвейер безопасного обновления

Хранилище конфигурации и контроль изменений

Для командной разработки важны:

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

возможность увидеть, кто и что менял

возможность откатиться или собрать релиз

В экосистеме 1С для этого часто используют:

хранилище конфигурации

организационные практики: код-ревью, ветвление по задачам, релизные теги

Вне зависимости от конкретного инструмента, дисциплина одна:

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

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

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

Администрирование для разработчика

Разработчик в 1С почти неизбежно сталкивается с администрированием, потому что именно там проявляются проблемы производительности, блокировок и “странного поведения”.

Резервное копирование и восстановление

Минимальный стандарт проекта:

регулярные резервные копии

периодическая проверка восстановления на тестовом стенде

отдельное хранение бэкапов от сервера базы

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

Журналы и диагностика

Что полезно уметь находить:

ошибки проведения и записи

ошибки обменов

исключения в серверных процедурах

долгие операции и проблемные места

На стороне разработки это означает:

внятные тексты ошибок

аккуратное использование Попытка ... Исключение ... КонецПопытки

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

Блокировки и конкурентная работа

Даже если вы используете транзакции правильно (из темы про транзакции), остаются типовые причины проблем:

долгие транзакции “держат” блокировки и мешают другим пользователям

массовые обработки обновляют слишком много записей за один проход

запросы читают больше данных, чем нужно, и нагружают СУБД

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

минимизируйте время транзакции

в массовых обработках делайте пакетную обработку

сначала измеряйте проблему, затем оптимизируйте

Практика: как собрать всё в рабочий контур

Ниже — минимальная “боеспособная” схема работы, которая связывает всё из курса.

Контуры

разработка: место, где меняются метаданные и код

тестирование: проверка сценариев, интеграций, прав, обновлений

продуктив: база пользователей

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

Чек-лист перед релизом

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

проверены права на новые объекты и команды

прогнаны основные сценарии: ввод, проведение, отчёты

проверены интеграции: входящие и исходящие

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

Мини-сценарий “как в проекте”

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

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

учесть его в запросе отчёта или СКД

добавить передачу реквизита в интеграции

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

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

Итоги

интеграции в 1С строятся через планы обмена, HTTP/Web-сервисы и файловые загрузки, а качество определяется контрактом, логированием и защитой от дублей

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

обновления типовых требуют процесса: тестирование, регресс, разрешение конфликтов и резервное копирование

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

Полезные точки входа в официальные ресурсы:

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

1С:Информационно-технологическое сопровождение (1С:ИТС)