Что такое 1С — базовая модель для программиста

artifacts/chto-takoe-1c-bazovaya-model-dlya-programmista.html · domain: platform · week 1 · supplement

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

Какие проблемы решает Ментальная модель Слои 1С Где там код Почему это важно для MCP

1. Какую проблему вообще решает 1С

Представь компанию. Ей нужно не «посчитать факториал» и не «написать HTTP API с нуля», а вести бизнес-состояние:

Справочники

Кто есть кто: товары, склады, контрагенты, сотрудники, договоры. Это master-data.

Документы

Что произошло: поступление товара, продажа, списание, начисление зарплаты. Это business events.

Регистры

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

Отчёты и формы

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

Если ты писал на C/C++/Go/Python, то обычно сам выбирал библиотеку UI, ORM, миграции, авторизацию, отчёты, роли, транзакции. В 1С большая часть этой инфраструктуры уже встроена, потому что домен повторяется: учётные бизнес-приложения.

2. Самая полезная аналогия

1С ближе не к «языку», а к связке runtime + framework + DSL + database mapping + admin tools.

Если сравнивать с твоим опытомВ 1С это похоже на...Но отличие
Python + Django Admin + ORMЕсть модели, формы, права, списки, отчётыВ 1С модель задаётся метаданными, а UI/хранение часто генерируются платформой
Go backend + PostgreSQLЕсть бизнес-логика, транзакции, данныеНе надо вручную проектировать все таблицы: объект конфигурации сам разворачивается в хранение
Solidity smart contractЕсть бизнес-события, состояние, инвариантыНо 1С — не immutable ledger; это enterprise runtime с пользователями, документами и отчётами
C/C++ runtimeЕсть платформа, которая исполняет кодНо прикладной смысл живёт не только в коде, а в метаданных конфигурации

3. Три слоя: платформа, конфигурация, информационная база

Платформа 1С runtime, UI, storage mapping, права, транзакции, отчёты Конфигурация описание приложения: справочники, документы, код Информационная база конкретные данные компании + загруженная конфигурация Что происходит при запуске прикладного решения 1. Платформа открывает информационную базу. 2. Читает из неё конфигурацию: какие объекты, формы, права, модули существуют. 3. Показывает пользователю интерфейс и исполняет бизнес-логику по правилам конфигурации. 4. Данные хранятся в SQL/файловой базе, но смысл данных задают метаданные 1С.

Платформа

Как Python interpreter или JVM, но с огромным встроенным фреймворком для учётных систем.

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

Конфигурация

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

проектируетсяизменяется

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

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

наполняетсябэкапится

4. Где в 1С «код», если всё через метаданные

Код есть, но он не единственный центр системы. В 1С много смысла живёт в свойствах объектов конфигурации.

Объект конфигурации Например: Документ ПоступлениеТоваров • реквизиты: Склад, Дата • табличная часть: Товары • формы: список, документ • права доступа • модуль объекта: код • проведение: движения Платформа строит UI формы, списки, команды, стандартные действия Платформа хранит данные в таблицах, но не как «голый SQL app» BSL-код дополняет правила, проверки, проведение, интеграции и нестандартную логику

Например, в Go ты бы написал structs, SQL migrations, HTTP handlers, UI отдельно. В 1С ты создаёшь объект «Документ», добавляешь реквизиты и табличные части, а платформа уже понимает: это документ, у него есть номер, дата, проведение, формы, движения, права, журнал документов.

// Псевдомодель мышления, не настоящий BSL
Конфигурация.Метаданные = {
  Справочник: "Номенклатура",
  Справочник: "Склады",
  Документ: "ПоступлениеТоваров" {
    Реквизит: "Склад",
    ТабличнаяЧасть: "Товары" { Номенклатура, Количество },
    ПриПроведении: "увеличить остатки на складе"
  },
  РегистрНакопления: "ОстаткиТоваров"
}

5. Жизненный цикл бизнес-события

Главная единица мышления в 1С — не endpoint и не таблица, а бизнес-событие, обычно документ.

1. Пользователь вводит документ.
Например: «Поступление товаров» — какой склад, какие товары, сколько штук.
2. Документ записывается.
Пока он может быть просто черновиком факта: данные есть, но ещё не изменили остатки.
3. Документ проводится.
Платформа вызывает код проведения. Он создаёт движения по регистрам: например, +10 единиц товара на склад.
4. Отчёты читают регистры.
Остатки склада считаются не из самого документа, а из накопленных движений и итогов регистра.
5. Write tools опасны.
Если MCP «просто поменяет таблицу», он может обойти проведение, права, проверки и сломать смысл учёта.

6. Почему для MCP нельзя думать «сделаем SQL-wrapper»

Физически данные 1С часто лежат в SQL-базе. Но прямой SQL видит только таблицы. Он плохо видит бизнес-смысл:

SQL-wrapper видит

Таблицы, колонки, индексы, строки. Иногда имена таблиц служебные и не похожи на бизнес-объекты.

MCP для 1С должен видеть

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

Главная граница

Read-only introspection безопаснее. Запись, проведение, изменение конфигурации — dangerous operations с подтверждением.

Ключевая мысль: 1С — metadata-driven система. Для MCP первый слой должен читать метаданные и объяснять структуру прикладного решения, а не давать агенту прямой доступ к физическим таблицам.

7. Мини-шпаргалка перед практикой

ТерминОчень простое объяснениеАналогия
ПлатформаПрограмма/runtime, которая исполняет 1С-приложенияPython interpreter + Django + admin/runtime, но специализировано под учёт
КонфигурацияОписание конкретного приложения: объекты, формы, код, праваПроект приложения + schema + modules
Информационная базаЭкземпляр приложения с реальными даннымиDatabase + deployed app config + users/settings
КонфигураторРежим разработки и администрированияIDE + migration/admin console
Пользовательский режимОбычная работа пользователя: документы, отчёты, справочникиProduction UI
СправочникОтносительно стабильные сущностиMaster-data table/model
ДокументСобытие бизнеса, которое может менять состояниеCommand/event with payload
РегистрХранилище движений и итоговEvent-derived ledger/projection

8. Что сделать руками, чтобы щёлкнуло

  1. Открой пустую учебную базу в Конфигураторе.
  2. Найди дерево конфигурации: Справочники, Документы, Регистры, Отчёты, Обработки, Общие модули.
  3. Создай мысленную карту: «это не папки с кодом, это типы бизнес-объектов».
  4. Запусти пользовательский режим и почувствуй разницу: Конфигуратор — где проектируют, пользовательский режим — где работают.

Откуда это построено