Как сделать типовую конфигурацию 1С: от идеи до рабочего решения

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

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

Ниже разобран полный цикл создания типовой конфигурации: от постановки задачи до поставки готового решения пользователям. Материал ориентирован на разработку на платформе 1С:Предприятие 8.3 в управляемом режиме.

Шаг 1. Проектирование структуры будущей конфигурации

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

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

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

Шаг 2. Создание пустой конфигурации в конфигураторе

Запустите конфигуратор и создайте новую информационную базу без конфигурации. Откройте конфигурацию (меню «Конфигурация» → «Открыть конфигурацию») — платформа предложит создать пустую структуру. Сразу задайте основные свойства корневого узла: имя, синоним, версию, поставщика, краткую информацию о назначении.

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

Создайте подсистемы — логические разделы интерфейса («Закупки», «Продажи», «Склад», «Отчёты», «Настройки»). Каждый объект метаданных позже привяжете к подсистемам, и пользователь увидит структурированный интерфейс вместо бесформенного списка.

1. 1
   Создайте новую информационную базу без конфигурации
2. 2
   Откройте конфигурацию и задайте имя, версию, поставщика
3. 3
   Установите управляемый режим и запретите модальность
4. 4
   Создайте подсистемы по разделам учёта
5. 5
   Настройте общие модули, картинки и стили интерфейса
6. 6
   Сохраните конфигурацию и обновите конфигурацию базы данных

Шаг 3. Разработка объектов метаданных

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

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

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

Документы и журналы

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

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

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

Шаг 4. Программирование логики проведения и модулей

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

Общий повторно используемый код выносите в общие модули. Разделяйте модули по назначению: серверные процедуры, клиентские обработчики, функции работы с конкретной подсистемой. Соблюдайте соглашения об именовании: например, «РаботаСДокументамиСервер», «ОбщегоНазначенияКлиент». Это облегчит сопровождение.

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

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    Движения.ОстаткиТоваров.Записывать = Истина;
    Для Каждого Строка Из Товары Цикл
        Движение = Движения.ОстаткиТоваров.Добавить();
        Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
        Движение.Период = Дата;
        Движение.Номенклатура = Строка.Номенклатура;
        Движение.Склад = Склад;
        Движение.Количество = Строка.Количество;
    КонецЦикла;
КонецПроцедуры

Шаг 5. Отчёты, права и интерфейс

Отчёты создавайте на системе компоновки данных (СКД) — она даёт пользователю гибкие настройки без программирования. Источник данных — запрос к регистрам с виртуальными таблицами («Остатки», «Обороты»). Добавьте варианты отчётов для типовых задач, чтобы пользователь не настраивал всё с нуля.

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

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

Шаг 6. Тестирование и сборка поставки

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

Проверьте конфигурацию встроенным механизмом: «Конфигурация» → «Проверка конфигурации». Включите проверки логической целостности, поиска некорректных ссылок и прав. Устраните все критичные замечания до поставки.

Для распространения решения используйте механизм поставки: «Конфигурация» → «Поставка конфигурации» → «Настройка поставки», затем «Создать файлы поставки и обновления». Платформа сформирует файлы .cf и .cfu, а также дистрибутив для установки через шаблоны. Укажите версию и опишите изменения — это важно для будущих обновлений у пользователей.

Шаг 7. Типичные ошибки и ограничения самостоятельной разработки

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

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

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

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