Обновление распределенных информационных баз (РИБ) в среде 1С — это процедура, требующая от администратора или программиста повышенной концентрации и четкого понимания внутренних механизмов платформы. Часто возникает соблазн сэкономить время и обновить периферийные (подчиненные) базы «одним махом» на несколько релизов вперед, особенно если центральная база уже успешно обновлена. Рассмотрим подробно, почему такой подход таит в себе скрытые угрозы, как устроен механизм обновления распределенных баз и какие практические методы помогут выполнить эту задачу безопасно.
Для того чтобы понять физику процесса, проанализируем, как происходит обновление современных конфигураций 1С (таких как «Розница», «Бухгалтерия предприятия», «Управление нашей фирмой» и других), построенных на базе БСП (Библиотеки стандартных подсистем). Любое обновление состоит из двух принципиально разных этапов:
Если мы обновляем центральную базу (ЦБ) последовательно, релиз за релизом, то на каждом шаге в режиме «Предприятие» успешно отрабатывают промежуточные обработчики. Но что происходит, если подчиненная база (РБ) обновляется скачком — например, сразу с релиза 2.2.11 на 2.2.13?
При обмене из центрального узла в подчиненный прилетает сразу финальная конфигурация релиза 2.2.13. При запуске периферийной базы БСП видит, что текущая версия данных — 2.2.11, а конфигурация уже 2.2.13. Система пытается запустить цепочку пропущенных обработчиков за все промежуточные релизы. Именно в этот момент велика вероятность столкнуться со следующими критическими проблемами:
2.2.12 разработчики переносили данные из старого поля Реквизит_Старый в новое поле Реквизит_Новый, а в релизе 2.2.13 старое поле было полностью удалено из метаданных. При «быстром» обновлении в РБ обработчик обновления попытается обратиться к полю Реквизит_Старый, но его уже физически нет в структуре базы данных. Произойдет аварийное завершение работы, и данные будут безвозвратно утеряны.---
Выясним причину частой иллюзии успешного обновления. Администратор последовательно обновил центральный узел (запуская «Предприятие» на каждом шаге), а затем запустил синхронизацию. Периферийные узлы получили финальный файл конфигурации и успешно открылись в режиме «Предприятие». Базы работают, пользователи не жалуются. Означает ли это, что все прошло гладко?
К сожалению, нет. Ошибки незавершенных обработчиков обновлений в РБ часто носят отложенный характер. Проблемы могут проявиться через недели или месяцы — например, при попытке провести старый документ, закрыть месяц, сформировать регламентированную отчетность или при очередном обновлении.
Выполним проверку состояния базы прямо сейчас. Для этого в каждой периферийной базе перейдем в раздел Администрирование — Обслуживание — Результаты обновления программы (или воспользуемся журналом регистрации, отобрав события по источнику БСП). Если там присутствуют невыполненные обработчики или ошибки с красными маркерами — структура данных нарушена. Для поиска расхождений в учете, которые могут возникнуть при некорректном выполнении обработчиков, применяется автоматическое сравнение бухгалтерских и налоговых проводок между базами 1С.
---
Рассмотрим по шагам рабочие сценарии, которые используют практикующие специалисты 1С для предотвращения и исправления подобных проблем.
Этот метод является самым надежным и рекомендованным фирмой 1С, так как гарантирует полную идентичность выполнения всех алгоритмов во всех узлах сети.
Разберем алгоритм действий:
Замечание: Если периферийных компьютеров много (например, более 5), данный метод становится крайне трудоемким. В таких случаях переходят к альтернативным сценариям.
Этот способ позволяет обновить подчиненную базу локально на торговой точке или удаленном офисе без передачи промежуточных файлов конфигураций по сети, что значительно экономит время и трафик.
Проанализируем шаги реализации этого метода:
// Отключаем главный узел, делая базу автономной
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
.cfu или полного .cf), обязательно запуская режим «Предприятие» на ключевых точках для выполнения обработчиков БСП.
// Находим узел центральной базы по коду и подключаем обратно
СсылкаНаЦБ = ПланыОбмена.ПоискПоКоду("ЦБ"); // Замените "ЦБ" на реальный код вашей центральной базы
Если ЗначениеЗаполнено(СсылкаНаЦБ) Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦБ);
Сообщить("Связь с главным узлом успешно восстановлена.");
КонецЕсли;
Если базы на периферийных компьютерах уже обновились «прыжком» через обмен и в них обнаружились скрытые ошибки обновления данных, самым быстрым и безопасным решением будет полная замена периферийных баз новыми образами.
Многие дилетанты боятся этого метода, опасаясь потерять настройки торгового оборудования (кассы, сканеры, эквайринг) или учетные записи локальных пользователей. Посмотрим, как сделать это правильно:
AppData или прописываются в реестре Windows. Также полезно сделать скриншоты или выписать параметры COM-портов, сетевых адресов весов и кассовых аппаратов.---
Если вы столкнулись с необходимостью обновить РИБ через несколько релизов, придерживайтесь следующих правил: