При работе в облачном сервисе 1С:Fresh пользователи и системные администраторы часто замечают интересную особенность: конфигурации в облаке могут функционировать на версиях платформы 1С:Предприятие, которых еще нет в свободном доступе на официальном портале обновлений. Например, при переходе на ветку 8.3.13 многие столкнулись с тем, что облачные базы уже вовсю работали на новой платформе, в то время как для локальных версий официальный релиз еще не был опубликован.
В рамках этой статьи мы подробно разберем, почему фирма «1С» использует облачный сервис в качестве пилотной площадки, с какими критическими техническими проблемами (такими как ошибка «ИБ не обнаружена» или пропажа 51 счета в ОСВ) можно столкнуться при обновлении платформы, и как эти проблемы оперативно решать.
Для многих специалистов становится открытием, что нумерация релизов платформы во «Фреше» часто не совпадает с тем, что выкладывают на партнерских сайтах и портале обновлений. Давайте выясним причины такой политики развертывания программного обеспечения:
rphost и оперативно исправлять их силами собственной разработки, не выпуская «сырые» релизы в коробках.data.dump) и загрузить ее в локальную версию программы возникает ошибка несовместимости версий. Локальная платформа ругается на то, что база создана в более новом релизе платформы, который физически еще нельзя скачать с сайта обновлений 1С. В таком случае приходится либо ждать официального релиза, либо использовать обходные пути конвертации.Одной из главных причин, почему администраторы спешат установить новые релизы (например, ранние сборки 8.3.13.1458), является исправление застарелых ошибок предыдущих веток. В частности, в ветке 8.3.12 часто проявлялась неприятная плавающая ошибка «Информационная база не обнаружена» или «Пользователь ИБ не идентифицирован».
Давайте проанализируем техническую суть этой проблемы. Эта ошибка чаще всего была связана с некорректным поведением кластера серверов 1С при маршрутизации сеансов и управлении блокировками. При определенных сценариях — например, при выходе пользователя из спящего режима, кратковременном обрыве сетевого соединения или во время выполнения фонового обновления конфигурации — менеджер кластера (процесс rmngr) терял связь с рабочим процессом (rphost), обслуживающим конкретную информационную базу. Из-за этого система считала, что база данных или сеанс пользователя отсутствуют на сервере, и выдавала пользователю пугающее сообщение.
В ветке 8.3.13 разработчики существенно переработали механизмы поддержания пула соединений и логику работы веб-сервисов, что позволило стабилизировать связь между тонким/веб-клиентом и сервером приложений. Однако вместе с исправлениями старых багов новые релизы принесли и новые неожиданные проблемы.
При обновлении локальных баз на ранние релизы платформы 8.3.13 (например, 8.3.13.1458) многие администраторы и бухгалтеры столкнулись с шокирующим поведением программы: в Оборотно-сальдовой ведомости (ОСВ) переставали отображаться некоторые счета, в частности активный 51 счет («Расчетные счета»).
Давайте разберем техническую причину этого бага. В платформе 8.3.13 фирма «1С» внесла серьезные изменения в работу механизма расширений конфигурации и оптимизировала запросы к виртуальным таблицам регистров бухгалтерии для повышения быстродействия. В результате этого в первых сборках проявился критический баг кэширования и индексации итогов. При обращении к регистру бухгалтерии платформа некорректно строила SQL-запрос к СУБД (особенно часто это проявлялось на СУБД PostgreSQL). Данные физически присутствовали в базе данных, но виртуальная таблица итогов их «не видела», из-за чего счета с активным движением просто исчезали из ОСВ или отображались с пустыми сальдо.
Если вы столкнулись с подобным поведением системы после обновления платформы, рассмотрим по шагам возможные варианты решения этой проблемы.
Для восстановления корректной работы таблиц итогов выполним стандартную процедуру пересчета через Конфигуратор:
Полный пересчет итогов регистров бухгалтерии заставляет платформу обновить и перестроить таблицы итогов в СУБД, что временно решает проблему отображения счетов.
Если у вас нет возможности монопольно запустить базу для пересчета итогов, можно попытаться изменить параметры формирования самой Оборотно-сальдовой ведомости. Иногда принудительное включение флага «Данные по забалансовым счетам» или изменение группировок в настройках ОСВ меняет структуру SQL-запроса платформы к СУБД, обходя проблемный участок кода, и счета снова начинают отображаться.
Если баг продолжает воспроизводиться, а стабильность учета в приоритете, наиболее надежным решением в продакшене остается откат на стабильную версию платформы предыдущей ветки (например, на стабильные релизы 8.3.12).
Помните золотое правило администратора 1С: не спешите внедрять самые новые релизы платформы на рабочие базы (продакшн) сразу в день их выхода. Оптимально протестировать новую платформу в течение месяца на копиях баз или дождаться выпуска корректирующих сборок (в случае с веткой 8.3.13 стабильная работа виртуальных таблиц была полностью восстановлена в релизах 8.3.13.1644 и старше).