Запуск УХ — это первая консолидация, которую финансовый директор подписал без пересчёта в Excel. Но через полгода после запуска многие группы обнаруживают, что база отстала от релизов на несколько версий, обмен с одной из дочек «иногда не проходит», а единственный человек, который понимал правила трансформации, перешёл в другую компанию. Сопровождение УХ — это не абонентская плата за звонки, а набор регулярных работ, без которых система за год превращается в дорогой архив.
Почему УХ сложнее сопровождать, чем бухгалтерию
У обычной учётной базы одна точка изменения — сама конфигурация. У УХ их как минимум три:
- сама УХ — релизы конфигурации и платформы, доработки, регламентированная отчётность для Казахстана (в документации УХ для Казахстана ей посвящена отдельная глава);
- источники данных — базы дочек, из которых УХ получает данные через прямое подключение, ADO или файлы. Обновилась Бухгалтерия у дочки — могли измениться объекты, на которые настроены правила;
- методика — виды отчётов, правила расчёта и проверки, регламенты подготовки отчётности, шаблоны процессов. Это не программный код, но меняется он чаще кода.
Сломаться может любая из трёх точек, и чаще всего ломается вторая. Подробно о том, как устроен сбор данных, — в статье «Сбор данных из дочерних баз в УХ».
Что входит в сопровождение
Мы делим работы на регулярные и разовые.
| Работа | Периодичность | Кто делает |
|---|---|---|
| Контроль закрытия периода: все ли экземпляры отчётов собраны, нет ли ошибок проверки | каждый отчётный период | методолог группы, консультант по запросу |
| Проверка обменов с дочерними базами после их обновлений | после каждого обновления дочки | консультант / программист |
| Обновление конфигурации и платформы | по плану, обычно раз в квартал | программист |
| Изменение видов отчётов и правил расчёта | по мере изменений методики | методолог, консультант |
| Пользователи, роли, права | по заявкам | администратор |
| Резервное копирование и проверка восстановления | ежедневно / раз в квартал | администратор |
Обратите внимание на последнюю строку. Резервная копия, из которой ни разу не пробовали восстановиться, — не резервная копия. Раз в квартал разворачивайте копию на тестовом сервере и открывайте в ней консолидированный отчёт за прошлый период.
Обновление конфигурации: порядок, который работает
Обновления УХ получают по подписке 1С:ИТС — 92 300 ₸ для уровня ПРОФ. Если подписка прервалась, догонять приходится цепочкой релизов, и это всегда дороже, чем обновляться регулярно.
Сам порядок мы держим одинаковым для любых баз с доработками:
- Копия рабочей базы на тестовом сервере. Никогда не обновляйте рабочую базу первой.
- Обновление на копии. Если конфигурация типовая — штатно. Если на поддержке с изменениями — через механизм сравнения и объединения конфигураций, который описан в документации платформы 1С:Предприятие. Каждое расхождение с новым релизом решает программист, а не «принять всё от поставщика».
- Сверка эталонных отчётов. До обновления сохраните 5–10 ключевых отчётов за закрытый период: консолидированный баланс, ОПиУ, отчёт по сверке ВГО, бюджет ДДС. После обновления сформируйте их снова и сравните. Расхождение даже в одной строке — повод разбираться до переноса.
- Проверка обменов. Запустите загрузку из одной-двух дочерних баз на копии.
- Перенос в рабочую базу — вне отчётной недели, с резервной копией перед обновлением.
Мы обновляем УХ не в первые дни после выхода релиза, а когда по нему накоплен опыт применения, — если только в релизе нет срочных изменений регламентированной отчётности.
Подробно о том, как обновлять большие базы с доработками, мы писали на примере ERP: «Обновление 1С:ERP с доработками». Принципы для УХ те же.
Доработки: чем меньше, тем дешевле каждый год
Каждая доработка в типовых объектах увеличивает стоимость каждого будущего обновления. Поэтому у нас на сопровождении три правила:
- Сначала настройка, потом код. Многое в УХ решается без программирования: видами отчётов, правилами расчёта, источниками данных, шаблонами процессов. Если задачу можно решить настройкой, код не пишем.
- Расширения вместо изменения типовой конфигурации, где это возможно. Механизм расширений платформы позволяет держать доработки отдельно от типовой конфигурации, и обновление проходит заметно проще.
- Реестр доработок. Таблица: что доработано, зачем, кто заказчик, в каких объектах. Без неё через два года никто не скажет, можно ли удалить странный реквизит в документе.
Если реестра нет, первая задача сопровождения — его составить. Это неделя работы, которая окупается на первом же обновлении.
Что ломается после обновления дочки
Это самый частый наш вызов на сопровождении УХ. Дочка обновила свою Бухгалтерию или КА, а в УХ после загрузки пустые строки или ошибка подключения.
Причина в том, что УХ при настройке импорта загружает структуру метаданных внешней базы и строит правила соответствия на её объектах. В документации это разделы «Импорт структуры метаданных внешних информационных баз» и «Настройка соответствия данных внешних информационных баз». Если в новой версии учётной программы изменился объект, на который опирается правило, данные перестают подтягиваться — иногда без явной ошибки.
Что мы советуем:
- договориться, что дочки обновляют учётные базы по согласованному графику, а не «когда бухгалтер нажал кнопку»;
- после обновления дочки — пробная загрузка в УХ за закрытый период и сравнение с прошлыми данными;
- держать в правилах проверки отчётов контроль «итог загруженного равен оборотам в источнике» — тогда расхождение видно сразу, а не на консолидации.
Методика тоже требует сопровождения
Новая дочка, новый сегмент, изменение учётной политики по МСФО — всё это правки в регламенте подготовки отчётности, видах отчётов и правилах трансформации. Здесь главный риск — правка «на живую» в середине закрытия. Правило простое: изменения методики — новой версией регламента и с начала нового периода, а не посреди сбора отчётности.
Второй риск — знание в одной голове. Мы просим у клиентов назначить методолога УХ на стороне группы и документировать каждое изменение методики в коротком журнале: дата, что изменили, почему. Часть типичных проблем, которые от этого возникают, разобрана в статье «Ошибки внедрения УХ».
Чек-лист первого месяца сопровождения
Когда мы принимаем УХ на сопровождение от другой команды или от собственного ИТ-отдела клиента, первый месяц уходит не на задачи пользователей, а на инвентаризацию. Что мы проверяем:
- версию конфигурации и платформы, отставание от актуального релиза;
- режим поддержки: типовая, на поддержке с изменениями, снята с поддержки;
- список доработок и расширений, есть ли их описание;
- все источники данных: какие базы дочек подключены, каким способом, кто отвечает за каждую;
- регламенты подготовки отчётности и их версии, какие из них реально используются;
- пользователей и роли: нет ли уволенных сотрудников с полными правами;
- резервное копирование: где копии, сколько хранятся, когда последний раз из них восстанавливались.
По итогам клиент получает короткий отчёт с рисками и план на квартал. Чаще всего первым пунктом в нём оказывается не обновление, а порядок в правах доступа и резервных копиях.
Своя команда или партнёр
| Вариант | Когда подходит | Риск |
|---|---|---|
| Свой программист и методолог | большая группа, много доработок, постоянные изменения | уход ключевого человека |
| Партнёр на сопровождении | доработок немного, изменения эпизодические | медленная реакция, если нет регламента вызова |
| Смешанный | свой методолог + партнёр для обновлений и сложных задач | нужен понятный раздел ответственности |
Для большинства групп мы рекомендуем смешанный вариант: методику должен знать человек внутри группы, а обновления и код удобнее отдать тем, кто делает это регулярно на многих базах.
О том, сколько стоит сама система и её внедрение, — в статье «Сколько стоит внедрение УХ», о продукте — в карточке 1С:Управление холдингом.
Частые вопросы
Как часто нужно обновлять УХ?
Регулярно, по плану — мы ориентируемся на квартал. Совсем без обновлений нельзя: в релизах приходят изменения регламентированной отчётности и исправления ошибок, а длинную цепочку пропущенных релизов догонять дольше и дороже.
Можно ли обновлять УХ без программиста?
Типовую конфигурацию без изменений — да, штатными средствами. Конфигурацию с доработками в типовых объектах — нет: объединение изменений требует решений программиста.
Что делать, если база давно не обновлялась?
Начать с аудита: какая версия, сколько и каких доработок, есть ли реестр. После этого составляется план перехода — иногда разумнее перенести доработки в расширения, чем объединять их через несколько релизов.
Нужна ли отдельная тестовая база?
Да. На ней проверяются обновления, новые правила расчёта и изменения методики. Тестовую копию стоит обновлять из рабочей перед каждой серьёзной проверкой.
