Как переносить бюджетные модели между базами 1С:УХ

Время на прочтение: 25 минут
Сложность: экспертная / продвинутая

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

Введение. Две базы - одна проблема

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

В 1С:УХ для переноса есть типовой инструмент - обработка «Выгрузка и загрузка методических моделей». Штука мощная, но, как любой сложный механизм, требует понимания: что именно она делает и, главное, чего она не делает.

О чем эта статья

Я поделюсь опытом, накопленным при реальных переносах бюджетных моделей. Мы разберем:

• Анатомию бюджетной модели - из каких кирпичиков она состоит и что чаще всего ломается при переносе.

• Чек-лист проверок «до» и «после» - чтобы не пропустить ни одной важной мелочи.

• Метод сверки двух моделей, которые развивались независимо - как не затереть чужую работу и сохранить все полезные наработки.

Важно: Этот материал является логическим продолжением моей предыдущей публикации, посвященной загрузке исторических данных в 1С:УХ (Как загружать исторические данные в 1С:Управление холдингом). Если тема миграции данных для вас актуальна - в той статье мы разбирали подготовку и наполнение бюджетной модели первичной информацией. Здесь же сосредоточимся на следующем этапе: переносе самой структуры и логики модели между базами.

Исходная картина

Представим классическую ситуацию. У нас есть две базы данных:

• База разработки и тестирования - здесь создаются и дорабатываются новые версии бюджетной модели.

• Промышленная база (ПРОД) - здесь модель работает в реальном режиме, на ней завязаны бюджетные процессы компании.

Задача: перенести изменения из первой базы во вторую, сохранив все настройки и не потеряв то, что уже работает в ПРОД'е.

Часть 1. Чек-лист проверок «ДО»

Прежде чем переносить бюджетную модель с помощью типовой обработки, нужно четко понимать, с какими объектами она связана. В первую очередь аналитик должен представлять внутреннюю архитектуру данных. Общая схема взаимосвязей справочников представлена на Рисунке 1.

Рисунок 1. Архитектура нормативно-справочной информации подсистемы бюджетирования

Диагностика бюджетной модели перед переносом

Перед переносом нужно убедиться, что в модели нет ошибок. Любая проблема, существующая в базе-источнике, автоматически перейдет в базу-приемник и может привести к полной или частичной потере работоспособности.

Все проверки разделены на два блока: информационная целостность (техническое состояние объектов) и логическая целостность (соответствие бизнес-требованиям).

Блок 1. Проверка информационной целостности (технические ошибки)

• ЦЕЛ.1. Поиск «битых» ссылок в источниках данных
  Запустите запрос из файла «ЦЕЛ.1. Запрос для поиска источников с битыми ссылками.q1c». Все найденные источники с несуществующими (битыми) ссылками нужно пометить на удаление (например, обработкой «Групповое изменение реквизитов»), а затем удалить штатными механизмами.

• ЦЕЛ.2. Проверка использования кода источника в формулах расчета
  Проверка обнаруживает ситуации, когда источник данных активен, но не используется в формулах.
  Выполните запрос из файла «ЦЕЛ.2. Запрос для проверки учета кода источника данных в формуле расчета.q1c». Все строки в результате - потенциальные ошибки: источник помечен как используемый, но в формулах не встречается.
  Иногда запрос дает ложные срабатывания из-за лишних пробелов в кодах. Например, вместо ожидаемого «Счет_26_ДО52» в базе может храниться с пробелами «Счет_26_ДО52 ». Два пути решения:

  1. Технический: создать обработку, которая автоматически чистит пробелы в кодах и представляет результат в нужном виде.

  2. Ручной: выгрузить результат в файл Excel и проверить формулой:
     =ЕСЛИ(ЕЧИСЛО(ПОИСК(СЖПРОБЕЛЫ(A1); B1)); "Найден"; "Не найден"),
     где A1 - код источника, B1 - формула расчета (например, [Счет_25_СНД] + [Счет_26_ДО52]).

• ЦЕЛ.3. Проверка заполненности аналитик в источниках данных
  Значения показателей должны передаваться по цепочке без потери глубины аналитики. Любая незаполненная аналитика - это ошибка, которая снижает качество данных. Даже если аналитику нельзя указать динамически, всегда можно установить фиксированное значение (см. Рисунок 2).

Рисунок 2. Табличная часть «Правила заполнения полей» источника данных с фиксированным значением

Запрос «ЦЕЛ.3. Запрос для поиска источников данных с незаполненными правилами по сбору аналитик.q1c» отбирает все источники, в которых настройка аналитики выполнена не полностью.
Примечание: приложенный запрос ориентирован на четыре стандартных аналитических признака («Номенклатура», «Контрагенты», «Подразделение организации», «Направления деятельности»). При необходимости доработайте этот запрос под особенности своей бюджетной модели.

• ЦЕЛ.4. Проверка корректности суммовых формул в групповых показателях
  Комплексный запрос «ЦЕЛ.4. Запрос для комплексного поиска ошибок в суммовых формулах.q1c» анализирует источники данных в групповых строках и выявляет:

  • Некорректные ссылки - групповая строка пытается собрать данные из другого вида отчета, другой колонки или регистров. Для групп допустим только сбор из дочерних строк этого же отчета.

  • Недопустимые ссылки - ссылка на показатель, не являющийся дочерним (например, из другой ветки или вышестоящий).

  • Замыкание на себя - источник ссылается сам на себя. Лечится, как правило, пересохранением формулы.

  • Отсутствующие ссылки - в формуле нет ссылок на дочерние строки.

  • Дубли - одна дочерняя строка учитывается в формуле несколько раз.

После исправления всех ошибок повторный запуск запроса должен вернуть пустой результат.

Блок 2. Проверка логической целостности (соответствие бизнес-логике)

Набор логических проверок индивидуален для каждого проекта. Ниже - примеры из реальной практики.

• ЛОГ.1. Проверка связи бюджетной модели со статьями оперативного контура

Допустим, в модели принято, что все статьи доходов/расходов (ДиР) и и движения денежных средств (ДДС) должны быть связаны со строками отчетов. Запрос «ЛОГ.1. Проверить связь бюджетной модели со статьями оперативного контура.q1c» покажет как строки без статей, так и статьи, не используемые в модели.

• ЛОГ.2. Проверка связи подразделений с ЦФО
  Элемент справочника «Организации» с типом «ЦФО или консолидирующая организация» является ключевым измерением подсистемы бюджетирования. Каждое структурное подразделение (из справочника «Структура предприятия») должно быть привязано к организации. Запрос «ЛОГ.2. Проверка связи каждого подразделения с ЦФО.q1c» выявит все подразделения без такой связи (актуально для 1С:ERPУХ).

• ЛОГ.3. Проверка сдвига периода для «Остатков на начало»
  У источников, связанных с колонкой «Остатки на начало периода», должен быть настроен сдвиг периода на -1. Это позволяет получать начальные остатки из конечных остатков прошлого периода. Без сдвига вычисления зацикливаются. Ручной поиск таких ошибок трудоемок, запрос «ЛОГ.3. Проверка настройки сдвига срока на -1.q1c» делает его мгновенным.

• ЛОГ.4. Проверка связи с историческими данными (при использовании промежуточных регистров)

Если для сбора исторических данных используется дополнительный регистр накопления (например, «Отчетность бюджетирования», см. статью на Инфостарте (//infostart.ru/1c/articles/2624130/ )), проверка проста: строка и колонка в показателе отбора должны совпадать со строкой и колонкой в связанном регистре. Пример - в запросе «ЛОГ.4. Корректность связи с историческими данными если используется дополнительный регистр накоплений.q1c».

• ЛОГ.5. Проверка ссылок в табличной части «Отбор по параметрам»

При настройке отборов со способом «Фиксированное значение» в источниках данных недопустимо указывать групповые элементы справочников. Запрос «ЛОГ.5. Проверка корректного указания ссылки на элемент для групповых значений.q1c» поможет найти такие ошибки. Актуально для справочников с видом иерархии «Иерархия групп и элементов».

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

Вывод по разделу

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

Приведение НСИ в соответствие: база разработки и промышленная база

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

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

Шаг 1. Определяем список используемых справочников

Запрос «СПР.1. Запрос для получения списка справочников, используемых в бюджетной модели.q1c» покажет, с какими типами данных работает модель.

Пример результата полученные на базе одной из реальных бюджетных моделей (см. Рисунок 3).

Рисунок 3. Перечень справочников, задействованных в рамках бюджетной модели (пример).

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

Шаг 2. «Вычистка» НСИ в базе разработки (проверенный метод)

Чтобы в бюджетной модели остались только актуальные элементы, существующие в ПРОД'е, следую следующим шагам:

1. Помечаю на удаление всё лишнее. В базе разработки помечаю на удаление все элементы справочников из полученного списка, которые задействованы в модели. Удобно использовать обработку «Групповое изменение реквизитов».

2. Выгружаю эталон из ПРОДа. С помощью обработки «Выгрузка и загрузка данных XML» (см. описание на ИТС https://its.1c.ru/db/metod8dev/content/4126/hdoc) выгружаю из промышленной базы все элементы тех справочников, которые попали в список задействованной НСИ.

3. Загружаю и снимаю пометки. Загружаю XML-файлы обратно в базу разработки. Система автоматически находит соответствующие элементы и снимает с них пометку удаления.

4. Удаляю «мусор». Запускаю типовую обработку «Удаление помеченных объектов». В результате из базы разработки удаляются все элементы НСИ, которых нет в ПРОД'е. Модель теперь ссылается только на «чистые», актуальные элементы.

Шаг 3. Контрольная сверка

Для подстраховки можно выполнить сверку GUID'ов элементов между двумя базами:

• Выгрузите списки элементов из базы разработки и ПРОДа с уникальными идентификаторами GUID (для получения GUID'ов используйте функцию языка запросов 1С «УНИКАЛЬНЫЙИДЕНТИФИКАТОР»).

• Сравните файлы в Excel с помощью ВПР (VLOOKUP).

Объем данных здесь обычно невелик, такую сверку можно сделать автоматизировано с использованием EXCEL-форм.

Критерий успеха: ни один элемент НСИ, используемый в модели, не должен быть помечен на удаление.

Следуя этому алгоритму, вы гарантируете, что после переноса все ссылки будут вести на корректные элементы, и проблем с дублями или «битыми» ссылками не возникнет.

Вывод по разделу

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

Описанный алгоритм («пометка на удаление ? выгрузка эталона из ПРОДа ? загрузка ? удаление лишнего») позволяет гарантированно «приземлить» модель на те элементы НСИ, которые уже живут и работают в промышленной среде. Контрольная сверка GUID'ов дает финальную уверенность, что после переноса не возникнет проблем с дублями или «битыми» ссылками.

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

Чек-лист: готовы ли вы к переносу бюджетной модели?

Перед запуском типовой обработки по переносу бюджетной модели убедитесь, что выполнены все подготовительные проверки. Чек-лист ниже объединяет требования к целостности модели (раздел 1.1) и согласованности НСИ (раздел 1.2).

!!! ВАЖНО: последствия небрежной работы с НСИ

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

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

• сбоям при закрытии месяца;

• некорректному расчету себестоимости;

• ошибкам в регламентированной отчетности.

Убедитесь, что все элементы НСИ, задействованные в модели, существуют в ПРОД'е, имеют там корректные настройки и не помечены на удаление. Только тогда можно гарантировать безопасный перенос.

Часть 2. Перенос модели: работа с обработкой «Выгрузка и загрузка методических моделей»

Типовой механизм переноса бюджетных моделей в 1С:Управление холдингом реализован в обработке «Выгрузка и загрузка методических моделей». Интерфейс обработки интуитивно понятен и состоит из двух вкладок: «Выгрузка моделей» и «Загрузка моделей». Подробная информация по работе доступна в контекстной справке (клавиша F1).

Рисунок 4. Обработка «Обмен методическими моделями», вкладка «Выгрузка моделей»

Рисунок 5. Обработка «Обмен методическими моделями», вкладка «Загрузка моделей»

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

«Обработка может использоваться только в тех случаях, когда информационная база, в которой осуществлялась выгрузка данных, и та, в которой данные загружаются, являются однородными (конфигурации идентичны, данные могут различаться), либо все выгружаемые объекты практически полностью идентичны по составу и типам реквизитов и табличных частей»

На практике это означает, что любые проблемы при переносе почти всегда являются следствием расхождения в структурах данных между базой-источником и базой-приемником. Обработка честно переносит объекты, но не может «подстроить» их под изменившееся окружение. Именно поэтому этапу предварительной сверки НСИ и проверки целостности модели (см. Часть 1) следует уделить первостепенное внимание.

Контрольная проверка после загрузки

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

Успешное прохождение контрольных проверок - сигнал к тому, что модель готова к дальнейшей эксплуатации.

Часть 3. Массовый перенос: обновление сразу многих видов отчетов

При работе с десятками видов отчетов стандартный подход «все в одном файле» может стать проблемой. Например, полная выгрузка бюджетной модели из 50 видов отчетов способна занять 2 часа, породив XML-файл объемом 6 ГБ, который затем будет загружаться еще 4 часа. В таких случаях разумнее выгружать каждый вид отчета отдельно - это упрощает контроль и ускоряет повторные переносы.

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

3.1. Сравнение моделей через анализ источников данных

Еще один подход к контролю разночтений между базами - анализ источников данных с использованием теории множеств. Для наглядности можно использовать диаграммы Венна, но сам метод основан на формальном сравнении составов множеств (см. Рисунок 6).

Рисунок 6. Пересечение множества источников данных базы разработки и базы ПРОД

Суть метода:

• Множество A - все источники данных в базе разработки и тестирования.

• Множество B - все источники данных, работающие в промышленной базе (ПРОД).

Нас интересуют две разности:

• A–B - новые источники, которые планируется перенести из разработки в ПРОД.

• B–A - источники, созданные непосредственно в ПРОД. Это зона риска: при обновлении модели они могут быть потеряны, что приведет к поломке работающих механизмов базы ПРОД.

Как выполнить это сравнение на практике

1. Получаем данные. Запускаем запрос «ПРВ.1. Запрос для выгрузки перечня GUID-ов источников данных с последующим сравнением в EXCEL.q1c» в обеих базах. На выходе - списки GUID'ов источников данных (множества A и B). Важно: запрос фиксирует только появление новых источников, изменения в настройках уже существующих не отслеживаются.

2. Сравниваем. С помощью специального Excel-файла «Сравнение источников данных разных баз данных.xlsx» вычисляем разности множеств (A–B) и (B–A).

3. Интерпретируем результат. Например, для бюджетной модели в рамках моего проекта мощности множеств оказались следующими:

   • |A–B| = 3235 - в базе разработки есть 3235 новых источников данных, которых нет в ПРОД.

   • |B–A| = 132 - в ПРОД есть 132 источника данных, которые отсутствуют в базе разработки.

Что делать с «лишними» источниками в ПРОД (множество B–A)

Эти 132 источника - зона особого внимания. И тут возможны два варианта:

• Они уже продублированы новыми источниками данных в базе разработки и значит ничего не нужно делать, кроме собственно переноса бюджетной модели.

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

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

Важно понимать последствия. Если просто загрузить новую модель поверх существующей, источники из множества B–A физически останутся в базе, но перестанут участвовать в расчетах:

• Они исчезнут из служебного регистра «Процедуры расчетов».

• Они пропадут из формул при открытии вида отчета через «Конструктор отчета».

• Они будут отображаться как ошибки по результатам отработки запроса ЦЕЛ.2 (проверка использования кода источника в формулах расчета).

Таким образом, контрольный запрос ЦЕЛ.2 после загрузки новой модели автоматически подсветит все «осиротевшие» источники, которые были в ПРОД, но не попали в обновление. Это удобный финальный инструмент контроля для аналитика.

Итог: семь шагов, которые работают

Перенос бюджетной модели в 1С:УХ между разными базами - это не кнопка «выгрузил-загрузил». Это процесс, который требует системы. Если вы дочитали до этого места, у вас уже есть все необходимые инструменты. Осталось только собрать их в единый, проверенный на практике алгоритм.

Вот он. Семь шагов, которые отделяют работающую модель от груды «битых» ссылок.

• Шаг 1. Проверьте версии. Убедитесь, что база-источник и база-приемник работают на идентичных версиях конфигурации 1С:Управление холдингом. Разные версии - самая частая причина необъяснимых ошибок.

• Шаг 2. Техническая диагностика (источник). Запустите запросы группы «ЦЕЛ.Х». Найдите и исправьте «битые» ссылки, некорректные коды, проблемы в формулах. В базе-источнике должно быть чисто.

• Шаг 3. Логическая диагностика (источник). Запустите запросы группы «ЛОГ.Х». Проверьте, соответствуют ли настройки модели вашей бизнес-логике: все ли статьи привязаны, все ли подразделения имеют ЦФО, везде ли правильно настроены сдвиги периодов и прочие ваши личные логические правила.

• Шаг 4. Синхронизируйте НСИ. Приведите справочники базы-источника в соответствие с эталонной базой-приемником. Используйте метод «пометка на удаление + загрузка из XML», описанный в разделе 1.2. В источнике не должно быть «мусорных» элементов, на которые ссылается модель.

• Шаг 5. Сравните с предыдущей версией (если перенос не первый). Если в ПРОДе уже есть рабочая модель, выполните сравнение по GUID-ам источников данных (раздел 3.1). Найдите расхождения и осознанно решите, что переносить, а что оставить.

• Шаг 6. Выгружайте и загружайте. Одним файлом или отдельно по видам отчетов - выбирайте по ситуации. Главное - выполнить перенос.

• Шаг 7. Финальная диагностика (приемник). Повторите шаги 2 и 3, но уже в базе-приемнике. Убедитесь, что все проверки проходят успешно.

С вероятностью 98% результат будет положительным. Почему не 100%? Потому что подсистема бюджетирования 1С:УХ - живой, сложный организм. Она постоянно развивается, обновляется, а вместе с ней меняются и модели. Абсолютной гарантии не даст никто. Но если вы прошли по этим семи шагам - вы сделали всё возможное, чтобы модель заработала именно так, как задумано.

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