← На главную
Ситуация, когда после масштабного внедрения предприятие получает глубоко кастомизированную конфигурацию 1С:ERP Управление предприятием, является одной из самых распространенных проблем корпоративного сектора. Изменение типовых механизмов напрямую в коде приводит к тому, что плановые обновления конфигурации становятся чрезмерно дорогими или технически невыполнимыми, а регулярные изменения законодательства ставят под угрозу своевременную сдачу регламентированной отчетности. Попытка руководства бездумно растиражировать такую базу на другие дочерние общества только масштабирует технический долг.
Разберем по шагам, как оценить текущее состояние системы, снизить риски и выстроить надежную архитектуру сопровождения и обновления доработанной 1С:ERP.
Анализ причин сложности обновления между поколениями ERP
Прежде чем принимать решение о полном перезапуске проекта или начале миграции, проанализируем, почему обновление сильно измененной конфигурации 1С:ERP (особенно при переходе с версий 2.1 на 2.4 и 2.5) представляет собой отдельный инженерный проект:
- Смена архитектурных концепций подсистем: в версиях линейки 2.1 использовалась модель производства на базе маршрутных листов (контур
Производство 2.1), тогда как в актуальных версиях применяется механизм этапов производства (контур Производство 2.2 / 2.5). Прямое наложение обновлений на переписанные модули производства приводит к разрушению логики проведения документов. - Трансформация партионного учета и себестоимости: вендор полностью переработал партионный учет и регистры накопления (включая регистр
ВыручкаИСебестоимостьПродаж, регистры учета дополнительных расходов и партий). Если в закрытие месяца внедрялись ручные корректировки движений или собственные алгоритмы, автоматический расчет себестоимости перестает сходиться. - Эволюция Библиотеки стандартных подсистем (БСП): с каждым мажорным релизом меняется состав и сигнатуры методов общих модулей. Прямые вызовы типовых функций в кастомном коде вызывают критические ошибки выполнения.
Решение 1. Разделение контуров: вынос регламентированного учета в типовую 1С:Бухгалтерию
Основным драйвером срочных и регулярных обновлений является изменение форм регламентированной и налоговой отчетности (НДС, декларации, форматы электронных документов). Попытка ежеквартально обновлять переписанное производственное ядро ради новых бланков несет колоссальные трудозатраты.
Рассмотрим проверенную архитектурную схему — переход на двухконтурную модель:
- Операционный контур (1С:ERP): в кастомизированной базе отключается или сворачивается регламентированный учет. Система используется исключительно для оперативного контура — планирования, производства, управления складом, закупками и продажами. База перестает зависеть от срочных обновлений законодательства и переводится на плановые технологические релизы 1–2 раза в год.
- Регламентированный контур (1С:Бухгалтерия КОРП): создается отдельная база с полностью типовой конфигурацией. В ней настраивается план счетов, налоговый учет и формируется регламентированная отчетность.
- Интеграция: настраивается регулярный обмен данными между 1С:ERP и 1С:Бухгалтерией. Передаются агрегированные или очищенные документы (поступления, реализации, списания, банковские выписки). Типовая база бухгалтерии обновляется штатными средствами в день выхода официальных релизов без риска поломки кастомных производственных цепочек.
Решение 2. Постепенный рефакторинг и изоляция доработок
Если эксплуатация единой базы 1С:ERP признана необходимой, следует поэтапно локализовать кастомизированный код, чтобы минимизировать количество конфликтов при сравнении и объединении конфигураций.
Разберем по шагам правила технического рефакторинга:
- Сравнение с эталоном: берется исходный типовой релиз поставщика, на базе которого выполнялось внедрение, и выполняется трехстороннее сравнение с текущей рабочей конфигурацией. Составляется реестр всех изменений.
- Вынос логики из типовых модулей: все добавленные алгоритмы переносятся в собственные общие модули и отдельные подсистемы. Обработка событий объектов (перед записью, при проведении) переводится на подписки на события вместо прямой модификации модулей объектов.
- Использование расширений конфигурации: формы документов, кастомные отчеты и интерфейсные доработки переводятся в расширения. При модификации методов следует отдавать предпочтение директивам
&Перед и &После, избегая директивы &Вместо, так как она блокирует выполнение нового типового функционала при обновлениях. - Отказ от лишнего кода: при сопоставлении доработок с функционалом свежих версий 1С:ERP выявляются участки, которые вендор уже реализовал в типовом ядре. Кастомный код на таких участках полностью удаляется в пользу штатных механизмов.
Решение 3. Организация конвейера тестирования перед обновлением
Чтобы исключить простои предприятия и ошибки закрытия месяца при установке релизов, внедряем строгий регламент тестирования:
- Фиксация ключевых сценариев: формируется набор сквозных бизнес-процессов (закупка сырья -> выпуск продукции -> распределение затрат -> расчет себестоимости -> реализация -> формирование книги покупок и книги продаж).
- Регрессионное тестирование на копии: обновление всегда выполняется на актуальной копии рабочей базы. С помощью сценарных тестов или чек-листов проверяется работоспособность ключевых механизмов.
- Контроль закрытия месяца: обязательным критерием успешности обновления является прохождение всех регламентных операций процедуры
ЗакрытиеМесяца без ручных правок регистров накопления и сведений.
Решение 4. Архитектурный подход к тиражированию на филиалы (ДЗО)
Попытка скопировать глубоко доработанную базу одной дочерней компании на предприятия с другой спецификой (например, со строительной сферы на стивидорную деятельность порта) приводит к краху сопровождения. Для холдинговой структуры правильным решением является создание Корпоративного шаблона.
Разберем архитектуру слоев корпоративной системы:
- Базовый слой (Ядро вендора): типовая конфигурация 1С:ERP, обновляемая от поставщика.
- Корпоративный слой (Шаблон холдинга): единая для всех дочерних обществ нормативно-справочная информация (НСИ), корпоративные планы счетов, унифицированные бюджетные формы и правила внутригрупповых расчетов.
- Локальный слой (Специфика ДЗО): отраслевые особенности конкретного предприятия, подключаемые исключительно в виде внешних обработок, печатных форм и локальных расширений, не затрагивающих ядро системы.
Если у конкретного филиала объем операций невелик или учет сводится исключительно к первичным операциям, внедрение тяжелого экземпляра 1С:ERP нецелесообразно — для таких площадок используются облегченные конфигурации (1С:Управление торговлей или 1С:Бухгалтерия) с интеграцией в корпоративный контур.