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

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

Разберём, как работает система 1С на уровне принципов: что делает платформа, откуда берутся справочники и документы, как считаются остатки, где выполняется код и как базы обмениваются данными между собой. Без этого любое администрирование 1С превращается в гадание.

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

Начнём с того, что именно вы запускаете.

• 🧩 Платформа (технологическая платформа 1С:Предприятие 8.3) — это движок. Исполняемый файл 1cv8.exe, встроенный язык, язык запросов, работа с СУБД, формы, печать. Платформа сама по себе ничего не «знает» про бухучёт.
• 📦 Конфигурация — прикладное решение: «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Управление торговлей» и т.д. Это описание объектов (метаданные) плюс код на встроенном языке.
• 🗄️ База данных (информационная база) — собственно ваши данные: проводки, документы, справочники.

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

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

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

Файловый и клиент-серверный режимы работы

База 1С живёт в одном из двух режимов. Выбор между ними — это и есть «архитектура» в бытовом смысле.

Файловый режим. Вся база — это один файл 1Cv8.1CD в каталоге. Платформа обращается к нему напрямую. Ничего ставить дополнительно не нужно: запустил ярлык — работаешь.

• Подходит для одного пользователя или небольшой группы.
• Для совместной работы файл кладут в общую сетевую папку, но при десятке активных пользователей начинаются замедления и блокировки.
• Храните файловую базу на локальном диске или надёжном сетевом хранилище и делайте резервные копии: повреждение файла 1Cv8.1CD — одна из самых частых потерь данных.

Клиент-серверный режим. База хранится в промышленной СУБД, а между клиентом и СУБД стоит кластер серверов 1С.

Поддерживаемые СУБД: Microsoft SQL Server, PostgreSQL, Oracle Database, IBM DB2. PostgreSQL популярен, потому что бесплатен и работает на Linux.

Как идёт запрос в клиент-серверном варианте:

1. Клиент подключается к агенту сервера (ragent, по умолчанию порт 1540).
2. Агент передаёт работу менеджеру кластера (rmngr, порт 1541).
3. Менеджер распределяет сеанс по рабочим процессам (rphost) — именно они общаются с СУБД. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера.
4. Консоль администрирования кластера тоже ходит через агент.

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

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

Как 1С хранит данные: объекты метаданных

Данные в 1С описаны не таблицами СУБД напрямую, а объектами метаданных. Разработчик описывает объект в конфигураторе, а платформа сама создаёт под него нужные таблицы в базе.

Основные типы прикладных объектов:

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

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

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

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

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

Виды регистров и что они дают:

• 📊 Регистр накопления — остатки и обороты: товар на складе, задолженность. Отвечает на вопрос «сколько есть» и «сколько пришло/ушло».
• 🧾 Регистр бухгалтерии — проводки по плану счетов (Дт/Кт с суммой и аналитикой). На нём строится оборотно-сальдовая ведомость.
• 📅 Регистр сведений — значения, привязанные к периоду или ключу: курсы валют, цены номенклатуры.
• 🧮 Регистр расчёта — сложные расчёты с взаимозависимостью периодов, основа зарплатных начислений в ЗУП.

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

1. Пользователь нажимает Провести (или Провести и закрыть).
2. Платформа запускает в модуле документа обработку проведения.
3. Код формирует наборы движений и записывает их в регистры.
4. Отчёты читают регистры — и цифры «появляются».

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

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

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

Логику конфигурации пишут на двух языках.

Встроенный язык 1С. Синтаксис русский (есть и английские аналоги команд). Код не компилируется в отдельный .exe — платформа компилирует модули в байт-код при запуске и исполняет их внутри себя.

Код выполняется в двух контекстах, и это принципиально для клиент-серверной работы:

• 🖥️ Клиент — интерфейс, реакция на действия пользователя. Директива &НаКлиенте.
• ⚙️ Сервер — работа с базой, запросы, запись данных. Директивы &НаСервере и &НаСервереБезКонтекста.

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

Язык запросов. Для чтения данных используют отдельный SQL-подобный язык запросов. Он только читает — изменять данные запросом нельзя, запись идёт через объекты. Запрос к регистру остатков товаров выглядит так:

ВЫБРАТЬ
    Остатки.Номенклатура,
    Остатки.КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки() КАК Остатки
ГДЕ
    Остатки.КоличествоОстаток > 0

Так работают почти все отчёты: берут данные из регистров запросом и выводят в таблицу. Если нужно разобрать логику — изучайте конкретную процедуру в конфигураторе; чужой код лучше не менять в рабочей базе без расширения конфигурации .

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

Роли и права доступа: кто что видит

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

• Роль — объект метаданных, набор разрешений на объекты: читать, добавлять, проводить, удалять.
• Пользователь получает одну или несколько ролей. В типовых конфигурациях на БСП это удобно делать через профили групп доступа в разделе Администрирование → Настройки пользователей и прав.
• 🔒 RLS (ограничение на уровне записей) — более тонкий механизм: пользователь видит документы не всех организаций или складов, а только разрешённых. Задаётся в роли.

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

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

Отдельно стоит пароль администратора базы и администратора кластера серверов. Не пытайтесь «сбросить настройки» или пересоздавать кластер, если пароль потерян — так вы потеряете и данные. Для кластера штатный путь — остановить службу, восстановить рабочий каталог из резервной копии или обратиться к администратору сервера. Для прав пользователей внутри базы достаточно входа под учётной записью с полными правами.

Обмен данными и интеграция с другими системами

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

• 🔁 Планы обмена и синхронизация данных. Встроенный механизм, которым связывают, например, «Бухгалтерию» и «Зарплату». Обмен идёт пакетами изменений; настраивается в разделе Администрирование → Синхронизация данных.
• 🌐 РИБ (распределённая информационная база). Частный случай плана обмена: несколько узлов одной конфигурации с общей структурой, обмен файлами или через каталог. Подходит для филиалов со слабой связью.
• 📨 Формат EnterpriseData — универсальный XML-формат, на котором построена типовая синхронизация между разными конфигурациями.
• 🔌 Веб-сервисы (SOAP) и HTTP-сервисы. Способ отдать или принять данные по сети: 1С выступает и сервером, и клиентом. На них держится интеграция с сайтами и сторонними сервисами.
• 📥 OData (REST-интерфейс). Автоматический доступ к данным базы по стандартному протоколу — удобно для внешних систем, которым нужно читать справочники и документы.
• 🗂️ Внешние источники данных. Позволяют читать таблицы чужой СУБД прямо из 1С, как будто это свои объекты.

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

Частые вопросы