Как перейти на типовую конфигурацию 1С

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

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

Ниже разобран полный цикл: от диагностики текущего состояния базы до контрольной проверки после перехода. Материал ориентирован на конфигурации на платформе 1С:Предприятие 8.3 — «Управление торговлей», «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Комплексная автоматизация» и другие типовые решения.

Когда переход на типовую конфигурацию действительно нужен

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

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

Подготовка: аудит доработок и резервное копирование

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

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

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

Выбор способа перехода

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

Способы перехода на типовую конфигурацию

Возврат на поддержку и штатное обновление

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

Штатная обработка перехода от вендора

Для перехода между редакциями (например, с УТ 10.3 на УТ 11 или с УПП на КА/ERP) 1С публикует официальные инструкции и обработки переноса. Ограничение: переносятся только типовые данные.

Перенос данных через обмен XML в чистую базу

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

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

Пошаговый порядок перехода через чистую базу

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

1. 1
   Сделайте и проверьте резервную копию рабочей базы (выгрузка .dt плюс копия средствами СУБД для клиент-серверного варианта).
2. 2
   Создайте чистую базу из шаблона типовой конфигурации целевого релиза и обновите её до актуальной версии.
3. 3
   Перенесите справочники: контрагенты, номенклатура, склады, договоры, сотрудники — через обработку «Универсальный обмен данными в формате XML» или штатные механизмы синхронизации.
4. 4
   Введите начальные остатки на дату перехода: по складу, расчётам с контрагентами, денежным средствам, расчётам с персоналом — штатными документами ввода остатков новой конфигурации.
5. 5
   Если нужна история, перенесите документы за требуемый период и проведите их, контролируя ошибки проведения.
6. 6
   Сверьте итоги: оборотно-сальдовую ведомость, остатки по складу и расчётам в старой и новой базе на дату перехода.
7. 7
   Проведите параллельную эксплуатацию 2–4 недели, затем зафиксируйте переход и закройте старую базу на редактирование.

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

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

Проверка результата и параллельная эксплуатация

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

Контрольные точки

Как проверить результат

ОСВ по счетам на дату перехода

Норма

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

Тревожный признак

Расхождения по отдельным счетам — ищите неперенесённые остатки

Остатки товаров по складам

Норма

Количество и сумма совпадают по каждой позиции

Тревожный признак

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

Расчёты с контрагентами

Норма

Задолженность по каждому контрагенту и договору совпадает

Тревожный признак

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

Проведение новых документов

Норма

Документы проводятся без ошибок, отчёты формируются

Тревожный признак

Ошибки проведения, пустые проводки, незаполненные счета учёта

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

Типичные ошибки и ограничения

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

Ещё одно ограничение касается лицензий. Переход между редакциями (например, с «Управления торговлей» 10.3 на 11) может потребовать приобретения новой лицензии или апгрейда по программе обмена — этот вопрос уточняют у партнёра 1С до начала работ, чтобы не остановиться на полпути.

Что делать с необходимыми доработками после перехода

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

Маршрут решения

Как поступить с каждой доработкой

Аналог есть в типовом функционале текущего релизаОткажитесь от доработки и обучите пользователей типовому механизму

Доработка — отчёт, печатная форма или обработка без изменения типовых объектовПеренесите её во внешний отчёт/обработку или расширение

Доработка меняет логику проведения или структуру данныхОцените возможность перестроить процесс под типовую схему; если невозможно — реализуйте через расширение с минимальным вмешательством

Назначение доработки неизвестно и ею никто не пользуетсяНе переносите: зафиксируйте в акте аудита и архивируйте

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

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

Можно ли перейти на типовую конфигурацию без потери истории документов?

Да, но это самый трудоёмкий вариант. Документы переносят через обмен XML или конвертацию данных с последующим проведением, при этом расхождения в проводках между старой логикой и типовой почти неизбежны. На практике чаще переносят справочники и остатки на дату перехода, а историю оставляют в старой базе в режиме чтения — для налоговых проверок и справок этого достаточно.

Сколько времени занимает переход?

Зависит от объёма данных и числа доработок. Для небольшой базы с переходом на границу года и переносом только остатков работы обычно занимают от нескольких дней до двух-трёх недель с учётом тестирования. Полный перенос истории за несколько лет с доработанными правилами может занять месяцы. Точную оценку даёт только аудит конкретной базы.

Чем расширение отличается от доработки конфигурации?

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

Что делать, если штатной обработки перехода для моей пары конфигураций нет?

Используйте универсальные механизмы: обработку «Универсальный обмен данными в формате XML» для совместимых по структуре объектов или «Конвертацию данных» для написания собственных правил соответствия. Для справочников с простой структурой иногда достаточно выгрузки в табличный документ и загрузки штатной обработкой загрузки данных из таблицы.

Нужно ли привлекать специалиста или можно перейти самостоятельно?

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

Как не потерять доступ к старым данным после перехода?

Сохраните старую базу в режиме только для чтения: снимите у пользователей права на запись, оставив просмотр. Дополнительно храните выгрузку .dt и, для клиент-серверной базы, резервную копию СУБД на отдельном носителе. Проверьте, что архивная копия разворачивается и открывается — непроверенная копия не считается резервной.