Переход с 1С:УПП на ERP, УХ, ERP.УХ: какую конфигурацию 1С выбрать и как спланировать проект

1С:УПП долгие годы была базовой системой учета для многих российских компаний, но с 2027 года ситуация изменится — вендор прекратит поддержку, после чего критически важные обновления регламентированного учета перестанут выпускаться. Как спланировать замену 1С:УПП и на что перейти, чтобы не потерять управляемость учета и процессов? Архитектор департамента 1С ГК «КОРУС Консалтинг» Алексей Рыжаков разобрал особенности замены системы и поделился практическими наблюдениями из проектов миграции. 

Фирма «1С» планирует выпускать обновления 1С:УПП до конца 2026 года. В I квартале 2027 обновления возможны только в том случае, если они потребуются для сдачи отчетности за 2026 год. Изменения законодательства, вступающие в силу с января 2027 года, поддерживаться не будут, а с 1 апреля 2027 года фирма «1С» перестанет оказывать консультации по конфигурации.

Что произойдет, если откладывать переход

• Регуляторные риски. УПП перестанет получать изменения, необходимые для корректного бухгалтерского и налогового учета. Компаниям-пользователям придется дорабатывать формы, алгоритмы и отчетность самостоятельно. Ошибки могут привести к пересчетам, задержкам при закрытии периода и претензиям контролирующих органов.
• Технические ограничения. Конфигурация больше не развивается и не использует многие современные возможности платформы 1С. Совместимость с новым окружением, интеграциями и внешними системами придется обеспечивать доработками.
• Рост стоимости сопровождения. Чем дольше компания остается на сильно кастомизированной УПП, тем больше ресурсов требуется на поддержку старого кода, поиск специалистов и срочные исправления. При этом инвестиции идут не в развитие целевой архитектуры, а в продление жизни устаревшего ПО.
• Процессные ограничения. Новые бизнес-модели, площадки, юрлица и требования к аналитике приходится встраивать в систему, которая изначально проектировалась под другую технологическую и управленческую реальность.
• Риск аварийного проекта. Если начать миграцию слишком поздно, выбор решения, моделирование и перенос данных придется проводить в условиях жесткого дедлайна. Это повышает вероятность компромиссов в архитектуре и запуска неподготовленной системы.

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

Ниже — практический маршрут: с чего начинать переход с 1С:УПП, как выбрать между 1С:ERP, «1С:Управление холдингом» и «1С:ERP. Управление холдингом» и что подготовить до начала проекта.

Сроки зависят от охвата процессов, количества юрлиц в группе компаний, объема доработок, качества НСИ, числа интеграций и выбранной стратегии запуска. Локальная замена регламентированного контура с ограниченным набором интеграций может занять около 6–9 месяцев. Полноценное внедрение ERP с производством, закупками, складом, продажами и управленческим учетом обычно требует 12–18 месяцев.

Для крупного холдинга, где одновременно проект охватывает операционные процессы, корпоративные финансы, консолидацию отчетности и архитектуру нескольких информационных систем, переход нередко превращается в программу на 18–24 месяца и более. В таком случае систему запускают очередями: по контурам, юрлицам, площадкам или функциональным блокам.

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

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

Цели проекта перехода с 1С:УПП могут включать

• Сохранение стабильного бухгалтерского и налогового учета и сокращение рисков при закрытии периода;
• Развитие управленческого учета, план-фактного анализа и отчетности для руководства;
• Автоматизацию управления производством, закупками, запасами, складом, логистикой, продажами и ремонтами;
• Создание единого финансового контура группы компаний: бюджетирование, казначейство, МСФО и консолидация;
• Снижение зависимости от Excel и ручных операций, повышение качества данных и прозрачности процессов;
• Подготовку архитектуры к росту компании, запуску новых площадок и направлений деятельности. Подробнее о том, как строить архитектуру высоконагруженных систем 1С, рассказали в предыдущей статье.

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

1. Оперативный/управленческий учет (необходим для предоставления руководству информации для принятия решений);
2. Регламентированный учет (бухгалтерский и налоговый — для отчетности и соблюдения требований законодательства).

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

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

Пример из реальной практики в отрасли FMCG — учет ретро-бонусов, то есть вознаграждений торговой сети за объем продаж или участие в промо. Бизнесу важно видеть «чистую» маржу без влияния коммерческих договоренностей, а в регучете тот же бонус может проходить как «Прочие расходы» для корректного закрытия периода. В итоге, цифры по прибыльности в управленческой и регламентированной отчетности начинают расходиться. Таких мест в учете много, что в конечном счете приводит к конфликту интересов на проекте.

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

Когда цели разложены, выбор системы становится немного проще. В линейке 1С есть три флагманских продукта, которые могут стать заменой 1С:УПП. 

Решение ориентировано на корпоративные финансы и опирается на «1С:Бухгалтерию предприятия КОРП» для регламентированного учета. Продукт закрывает задачи бюджетирования, казначейства, управления договорами, учета по МСФО, консолидации отчетности и управления финансовыми рисками. Такой вариант подходит группам компаний, которым важен единый финансовый контур, но не требуется переносить в одну систему все производственные и логистические процессы.

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

Объединяет операционные возможности 1С:ERP с расширенной функциональностью корпоративных финансов 1С:УХ. Решение подходит крупным компаниям и холдингам, которым в одной архитектуре нужны производство и логистика, регламентированный учет, бюджетирование, казначейство, МСФО и консолидация.

Выбор конкретного решения снова упирается в вопрос: что первично — финансовый контур и стабильный регучет или операционка и процессы. Логика выбора такая:

• Если ключевой приоритет — стабильный регламентированный учет, закрытие периода и финансовая дисциплина, то стоит рассмотреть решение, где финансовая модель является базой: «1С:Бухгалтерия предприятия КОРП» или «1С:Управление холдингом» (если нужен контур корпоративных финансов, бюджетирование, МСФО, казначейство).
• Если нужно развивать управление производством, закупками, запасами, складом, продажами и затратами, базовым кандидатом становится «1С:ERP».
• Когда компании нужны и сквозные процессы ERP, и учет корпоративных финансов в единой архитектуре (особенно в группе компаний), логично рассматривать «1С:ERP.Управление холдингом».

1. Целевые процессы и функциональный охват: какие задачи должны войти в первую очередь, а какие можно внедрять последующими этапами.
2. Архитектуру регламентированного учета: в какой системе будут формироваться проводки и отчетность, потребуется ли разделение оперативного и финансового контуров.
3. Масштаб и структуру бизнеса: число юрлиц, площадок, филиалов, стран, производственных переделов и центров ответственности.
4. Требования к корпоративным финансам: бюджетирование, казначейство, МСФО, консолидация, управление договорами и внутригрупповыми операциями.
5. Интеграционный ландшафт: WMS, MES, CRM, EDI, оборудование, отраслевые системы, которые должны продолжить работу после перехода.
6. Объем наследия: критичные доработки УПП, зависимость процессов от нестандартных отчетов и обработок. 
7. Планы развития и стоимость владения: система должна поддерживать рост бизнеса без постоянного наращивания доработок.

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

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

План миграции данных следует строить по трем направлениям:

1. По составу данных и видам учета. Отдельно определяют, какие справочники, остатки, документы, обороты и аналитические регистры нужны для управленческого, бухгалтерского и налогового учета. Один и тот же показатель в УПП и целевой системе может формироваться из разных объектов, поэтому перенос нельзя проектировать как механическое сопоставление таблиц.
2. По уровню детализации данных. Для каждого объекта нужно решить, достаточно ли начальных остатков и агрегированных оборотов или требуется история до документа, партии, серии, заказа, проекта и подразделения. Чем глубже детализация, тем выше трудоемкость очистки, преобразования и сверки.
3. По периодам. Необходимо определить дату отсечения, глубину истории и порядок работы с данными до и после запуска. При переходе в середине года отдельно планируют информацию, которая нужна для отчетности нарастающим итогом, закрытия периода и продолжения незавершенных операций.

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

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

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

Для таких ситуаций мы выделяем три подхода:

• Перенос остатков на начало года + детальные обороты. Это сложно и трудозатратно.
• Перенос остатков на дату перехода + сводные обороты за прошлый период. Агрегировать данные, которые не влияют на будущие процессы, но важны для расчета показателей нарастающим итогом с точки зрения учета.
• Перенос остатков на дату перехода + точечная перестройка пострадавших процессов. Иногда дешевле «склеить» два отчета, чем переносить в систему огромный объем исторических данных.

Отдельная задача — незавершенные операционные цепочки. Заказ поставщику может быть создан в УПП, но товар поступит уже после запуска ERP, а счет-фактура и оплата появятся еще позже. Если перенести только остаток товара или задолженности, система потеряет связь между заказом, поступлением, резервом, документами расчетов и ответственными подразделениями. В результате пользователи не увидят актуальный статус операции, а в учете могут возникнуть дубли или разрывы. 

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

Что учитывать при реализации проекта, чтобы сократить риски ошибок:

1. Планировать дату миграции в период спада спроса, когда нагрузка на операционную деятельность компании снижается. Это упрощает жизнь при переносе данных и снижает риски потерь эффективности в первые недели после ввода системы в эксплуатацию. Проблемы после запуска бывают у всех — важно сделать их управляемыми.
2. Учитывать трудоемкость процесса переноса данных: есть операции, которые легко ложатся на типовую систему без доработок, а есть сложные цепочки, которые переносить гораздо сложнее. 
3. Учитывать объемы данных. Остатки по банку-кассе можно внести в систему операторским вводом. В то же время справочник номенклатуры со множеством единиц измерений, серий, десятками тысяч SKU будет сложно загрузить в целевую систему типовыми инструментами обмена, и нужно заранее продумать, как технически это организовать.

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

Попытка повторить логику УПП в целевой системе почти всегда увеличивает стоимость проекта: много доработок, сложные правила, высокая нагрузка на сопровождение.

Более управляемый подход — оценивать процессы через бизнес-цели:

• Какие процессы критичны и должны быть реализованы первыми;
• Какие вспомогательные и могут идти вторым приоритетом;
• От каких можно отказаться без влияния на результат.

Работает принцип Парето: 20% действий дают 80% результата. Если бухгалтер просит сделать в новой системе кнопку, которая формирует отчет на семь тысяч строк, нужно задаться вопросом: как эти семь тысяч строк влияют на бизнес-результат компании и достижение ее целей? Если никакой связи нет, то стоит задуматься, насколько это обязательный элемент новой системы.

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

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

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

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

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

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

Обычно моделирование включает

1. Сбор и приоритизацию ключевых сценариев: закупка, производство, продажа, закрытие периода, бюджетирование, казначейство и другие процессы;
2. Настройку демонстрационного контура и загрузку небольшого набора реальных или обезличенных данных;
3. Проведение рабочих сессий с бизнесом, финансовой службой и ИТ, где сценарии выполняются в системе от начала до конца;
4. Фиксацию решений, ограничений типовых возможностей платформы и функциональных разрывов;
5. Оценку доработок, интеграций, миграции, ролей пользователей и организационных изменений;
6. Подготовку целевой архитектуры, дорожной карты и уточненной оценки проекта.

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

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

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

Даже если проект еще не стартовал, компания может снизить будущие риски и сократить срок перехода:

• Минимизировать новые доработки УПП. Развивать старую конфигурацию стоит только там, где это необходимо для законодательства или критичного процесса.
• Провести первичный аудит системы. Зафиксировать используемые подсистемы, доработки, нестандартные отчеты, объемы данных, производительность и технические ограничения.
• Составить карту интеграций. Определить, с какими системами УПП обменивается данными, кто отвечает за каждый интерфейс и какие форматы необходимо сохранить или изменить.
• Привести в порядок НСИ. Удалить дубли, назначить владельцев справочников, заполнить обязательные реквизиты и при необходимости рассмотреть отдельную MDM-систему.
• Сформировать перечень целевых процессов и приоритетов. Отделить критичные требования первой очереди от функций, которые можно внедрять позже.
• Создать проектную команду. В нее должны войти представители бизнеса, финансов, ИТ и ключевые пользователи с полномочиями принимать решения.
• Выбрать подход к внедрению и ИТ-партнера. Важно оценивать не только стоимость разработки, но и опыт архитектуры, миграции, моделирования и запуска крупных систем. Подробнее о том, как выбрать партнера рассказали в материале — Как выбрать подрядчика для внедрения 1С.

Что это означает для проекта: чем лучше подготовлены данные и люди, тем меньше рисков в запуске и быстрее адаптация.

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

1. Проводим аудит текущей УПП: процессов, доработок, данных, интеграций и технического ландшафта.
2. Помогаем выбрать целевую конфигурацию и архитектуру: 1С:ERP, 1С:УХ, 1С:ERP.УХ или комбинированный вариант.
3. Проводим моделирование ключевых процессов и формируем дорожную карту внедрения.
4. Проектируем стратегию миграции данных и незавершенных операций, разрабатываем механизмы загрузки и сверки.
5. Реализуем интеграции, доработки, тестирование, обучение, опытную эксплуатацию и промышленный запуск.
6. Поддерживаем пользователей в период стабилизации и помогаем развивать систему.