При обновлении конфигурации «1С:Зарплата и управление персоналом» (ЗУП) системные администраторы и бухгалтеры часто сталкиваются с ситуацией, когда скачанное официальное обновление не применяется к текущей информационной базе. Программа выдает лаконичное, но ставящее в тупик сообщение: «Обновления не найдены». Особенно часто эта проблема проявляется при работе с параллельными ветками релизов, такими как 3.1.5 и 3.1.8.
В этой статье мы подробно разберем, почему возникает данная ошибка с точки зрения архитектуры платформы «1С:Предприятие», в чем заключается разница между версиями длительного сопровождения (LTS) и инновационными релизами, а также проанализируем критические изменения в учете НДФЛ и механизме распределения заработка, которые заставляют пользователей делать выбор между этими ветками.
---
Давайте проанализируем ситуацию, описанную пользователем: на компьютере установлена рабочая база 1С:ЗУП версии 3.1.8.216. Пользователь скачивает свежий релиз 3.1.5.407, запускает поиск обновлений через Конфигуратор или в режиме «1С:Предприятие», но система упорно отказывается видеть дистрибутив. Почему так происходит?
Дело в том, что в экосистеме 1С стандартный файл обновления с расширением *.cfu (Configuration Update) представляет собой «разницу» (дельту) между конкретными старыми версиями и новой версией. Этот файл технологически предназначен только для движения вперед по иерархии метаданных. Переход с версии 3.1.8 на версию 3.1.5 является «даунгрейдом» (откатом на более раннюю версию), который платформа осуществить в автоматическом режиме не может.
Путаница у пользователей часто возникает из-за специфики нумерации релизов 1С. Рассмотрим структуру номера версии конфигурации:
[Направление] . [Редакция] . [Ветка/Sub-version] . [Номер сборки]
В нашем примере мы имеем две версии:
3.1.8.216 — ветка 8, сборка 216.3.1.5.407 — ветка 5, сборка 407.Несмотря на то, что сборка 407 была выпущена позже по календарному времени, сама ветка 3.1.5 технологически старше, проще и имеет более узкую структуру метаданных, чем ветка 3.1.8. База данных версии 3.1.8 уже содержит новые справочники, измененные типы реквизитов и регистры сведений, которых физически нет в ветке 3.1.5. Платформа распознает попытку применить обновление 3.1.5.407 к базе 3.1.8.216 как некорректную операцию и сообщает, что подходящих файлов обновлений не обнаружено.
Для наглядности приведем пример кода, упрощенно демонстрирующего, как сама платформа проверяет совместимость версий при обновлении конфигурации:
// Примерный алгоритм проверки возможности обновления конфигурации
Функция ПроверитьСовместимостьРелиза(ТекущаяВерсияКонфигурации, ВерсияФайлаОбновления) Экспорт
МассивТекущихНомеров = СтроковыеФункцииКлиентСервер.РазложитьСтрокуВМассивПодстрок(ТекущаяВерсияКонфигурации, ".");
МассивНовыхНомеров = СтроковыеФункцииКлиентСервер.РазложитьСтрокуВМассивПодстрок(ВерсияФайлаОбновления, ".");
// Сравниваем суб-версию (третий сегмент номера релиза)
Если Число(МассивТекущихНомеров[2]) > Число(МассивНовыхНомеров[2]) Тогда
// Попытка даунгрейда, например с 3.1.8 на 3.1.5
Возврат Ложь;
КонецЕсли;
Возврат Истина;
КонецФункции
---
Зачем вообще фирма «1С» выпускает параллельно две ветки обновлений? Чтобы ответить на этот вопрос, разберем стратегию поддержки программных продуктов.
Версия 3.1.5 являлась официальной LTS-версией (Long-Term Support). Основные принципы разделения веток выглядят следующим образом:
Таким образом, крупным предприятиям с доработанными конфигурациями выгоднее оставаться на LTS-версии (такой как 3.1.5), чтобы минимизировать риски сбоев при расчете зарплаты. Обычные пользователи чаще стремятся переходить на инновационные ветки ради нового функционала.
---
Одним из ярких примеров того, почему пользователи стремятся остаться на более старой ветке 3.1.5, является кардинальное изменение документа Распределение основного заработка.
Выясним причину недовольства пользователей, сравнив реализацию этого механизма в двух версиях:
Это привело к значительному увеличению трудозатрат бухгалтеров, у которых расчет распределения завязан на сложную аналитику (например, распределение зарплаты производственного персонала по нескольким номенклатурным группам вручную). Из-за таких интерфейсных изменений многие компании сознательно блокировали обновление конфигурации выше версии 3.1.5.
---
Еще один аргумент против поспешного перехода на ветку 3.1.8 в период конца 2018 — начала 2019 года заключался в стабильности учета НДФЛ и корректности формирования отчетности по форме СЗВ-СТАЖ.
Разберем основные проблемы, с которыми столкнулись пользователи новой ветки:
3.1.8 был серьезно изменен внутренний механизм проведения документов в регистры накопления по учету доходов для исчисления НДФЛ. При зачете авансовых платежей по патентам у иностранных сотрудников происходило некорректное распределение сумм налога, из-за чего данные «плыли», а перепроведение документов не давало положительного результата. В ветке 3.1.5 этот функционал работал по старым, уже отлаженным алгоритмам.3.1.8 работал нестабильно, порождая массу предупреждений и ошибок при проверке отчета сторонними программами. В LTS-ветке 3.1.5 исправления выпускались точечно, проходя более строгий контроль качества.---
Если вы оказались в ситуации, когда ваша база уже имеет версию 3.1.8, а вы хотите вернуться на 3.1.5, рассмотрим возможные варианты действий.
Поскольку процесс автоматического даунгрейда невозможен, наиболее безопасным решением будет отказаться от идеи возврата на 3.1.5. Вам необходимо продолжить обновление вперед по ветке 3.1.8 (и далее на последующие ветки, например, 3.1.10, которая стала следующей стабильной LTS-версией). Все критические ошибки по НДФЛ и отчетности со временем исправляются разработчиками в новых релизах.
Если работа в версии 3.1.8 категорически невозможна (например, из-за критических ошибок доработок или полной несовместимости ваших внешних обработок), единственным способом вернуться на 3.1.5 является восстановление резервной копии базы данных, сделанной до начала процесса обновления на 3.1.8.
Важно: При восстановлении из резервной копии все данные, введенные пользователями после момента создания архива, будут утеряны, и их придется вносить в базу данных заново.
Если база уже долгое время велась в версии 3.1.8, но вам во что бы то ни стало нужно вернуться на 3.1.5 без потери введенных документов, стандартными средствами это сделать не получится. Потребуется использовать специализированную обработку ВыгрузкаЗагрузкаДанныхXML (версии, соответствующей вашей платформе) и правила конвертации данных, настроенные вручную. Этот процесс требует высокой квалификации программиста 1С и глубокого понимания структуры метаданных обеих версий конфигурации.