Разделение информационной базы — задача, с которой рано или поздно сталкивается любой администратор или программист 1С. Чаще всего это требуется, когда бизнес дробится, продается одна из компаний или база становится слишком тяжелой для файлового режима. Одним из наиболее популярных методов является использование механизма Распределенных Информационных Баз (РИБ) с фильтром по организации. Однако этот метод таит в себе скрытую опасность: на определенных версиях платформы вы можете получить базу, в которой оборотно-сальдовая ведомость (ОСВ) сходится, но аналитические отчеты (например, по складам) остаются абсолютно пустыми.
В этой статье мы подробно разберем, почему возникает проблема «пустой аналитики», как на это влияет версия платформы и какие альтернативные способы разделения существуют, если стандартный механизм РИБ дает сбой.
Рассмотрим типовую ситуацию. Вы создаете начальный образ подчиненного узла РИБ, устанавливаете фильтр по конкретной организации и отключаете новую базу от главного узла (переводите в автономный режим). На первый взгляд все выглядит идеально: итоговые суммы в ОСВ совпадают до копейки. Однако при попытке сформировать отчет «Ведомость по товарам на складах» или открыть «Карточку счета», вы обнаруживаете, что колонки Аналитика Дт и Аналитика Кт не заполнены. Склады в документах как будто «исчезли» для системы отчетов.
Выясним причину такого поведения. Это происходит из-за некорректного переноса Функциональных опций и Настроек параметров учета. В 1С:Бухгалтерии учет по складам и другим разрезам аналитики включается специальными константами. При создании РИБ с фильтром некоторые регистры сведений, не имеющие явного измерения Организация, могут не попасть в миграцию. В результате база «думает», что складской учет выключен, хотя сами данные в таблицах присутствуют. Система просто скрывает их при построении запросов в отчетах.
Как показывает практика и опыт участников сообщества, данная проблема часто носит платформенный характер. На определенных релизах (например, 8.3.22.2239) механизм сериализации данных при создании начального образа работал с ошибками в части функциональных опций.
Проанализируем успешный опыт решения: проблема полностью устраняется при использовании платформы версии 8.3.23.1997 или более поздних, таких как 8.3.24.1342. Новые версии платформы корректнее обрабатывают кэш конфигурации и настройки параметров учета при первом запуске подчиненного узла.
Если вы уже создали базу и столкнулись с проблемой, алгоритм действий должен быть следующим:
Важный нюанс при перепроведении: иногда 1С использует оптимизацию и не перезаписывает движения, если реквизиты документа не изменились. В таких случаях программисты прибегают к хитрости — программному изменению суммы или другого реквизита. Но мы рекомендуем использовать обработку Групповое изменение реквизитов. В ее дополнительных настройках можно включить режим «Сделать записи выбранных объектов незаписанными», что заставит систему принудительно обновить регистры бухгалтерии.
Если метод с РИБ кажется вам слишком сложным или нестабильным, разберем альтернативный, «железобетонный» способ — метод исключения лишнего. Этот способ особенно актуален для файловых баз, где нельзя быстро развернуть SQL-сервер для сложных манипуляций.
Пошаговый алгоритм:
Групповое изменение реквизитов, чтобы найти и пометить на удаление справочники, связанные только с удаляемыми организациями (например, банковские счета).Этот метод гарантирует, что все настройки аналитики, константы и параметры учета сохранятся в первозданном виде, так как вы не фильтруете данные при переносе, а удаляете лишнее из уже работающей структуры. Однако помните, что удаление большого объема данных в файловом режиме может занять значительное время.
После того как вы успешно разделили базу и проверили отчеты, необходимо обратить внимание на служебные данные. При разделении через РИБ часто «отваливается» механизм обновления классификаторов (банков, адресов и т.д.).
Посмотрим на регистр сведений ВерсииКлассификаторов. В новой базе он может оказаться пустым. Если это так, система будет считать, что справочники не загружены, даже если визуально данные на месте. Чтобы исправить это, необходимо перенести данные этого регистра из головной базы в новую с помощью внешней обработки или встроенных средств обмена (например, через XML). Без этого автоматическое обновление классификаторов может работать некорректно.
Если документов очень много, ручная пометка может быть утомительной. Рассмотрим пример простого кода, который поможет автоматизировать пометку документов на удаление по конкретной организации:
ВыборкаДокументов = Документы.РеализацияТоваровУслуг.Выбрать();
Пока ВыборкаДокументов.Следующий() Цикл
Если ВыборкаДокументов.Организация = НужнаяОрганизацияДляУдаления Тогда
Объект = ВыборкаДокументов.ПолучитьОбъект();
Объект.УстановитьПометкуУдаления(Истина);
Объект.Записать();
КонецЕсли;
КонецЦикла;
Конечно, для полноценной очистки лучше использовать универсальные обработки с возможностью поиска ссылок на объекты, чтобы не оставить в базе «мусорных» записей в регистрах сведений.
Подводя итог, отметим: разделение базы — это всегда риск потери целостности данных. Всегда делайте резервные копии перед началом работ и тщательно сверяйте не только ОСВ, но и детализированные аналитические отчеты после завершения процедуры.