Как узнать, в какой версии конфигурации были конкретные изменения
Добрый день. Ситуация: есть база 1С Erp Управление холдингом, версия 3.1.12.19. Проблема: пользователь сообщил, что с 01.01.2025 вступает закон об изменении в налоговом учёте (введение прогрессивной пятиступеньчетой шкалы ндфл) и, естественно, им надо, чтобы это работало в базе с 1 января. В настоящее время последняя доступная версия базы - 3.1.13.18, т. е. было поднятие релиза. Времени на обновления до конечной версии почти нет - база очень большая, с расширениями (>15) с серьёзными доработками, которые ещё и проверить на совместимость с новой конфигурацией базы. Можно ли как-нибудь узнать в какой версии базы есть изменения, связанные с новыми налогами? На сайте скачивания дистрибутива для обновления никакой информации об изменениях в версии не нашла.
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
на официальном сайте 1С у каждого обновления первая ссылка: "Новое в версии"
Прогрессивная шкала НДФЛ была добавлена в последнем обновлении ЗУП 3.1.30.108(дп) от 29.11.2024
У меня нет доступа к ерп, но могу предположить, что с большой долей вероятности надо искать релиз ерп после этой даты.
К примеру в обновлениях комплексной прямо указывается, какой релиз ЗУП в ней.
П.С. Странно конечно, что кто-то в 2024 умудряется вести зарплату(и, вероятно, бухучет) в базе, у которой какие-то сложности с обновлениями
Прогрессивная шкала НДФЛ была добавлена в последнем обновлении ЗУП 3.1.30.108(дп) от 29.11.2024
У меня нет доступа к ерп, но могу предположить, что с большой долей вероятности надо искать релиз ерп после этой даты.
К примеру в обновлениях комплексной прямо указывается, какой релиз ЗУП в ней.
П.С. Странно конечно, что кто-то в 2024 умудряется вести зарплату(и, вероятно, бухучет) в базе, у которой какие-то сложности с обновлениями
(3) П. С. База очень большая, я обычно выделяю как минимум 3-5 недели на обновление с большим количеством промежуточных апов, особенно с переходом на следующий релиз - неделя-полторы на обновление на тестовом сервере, по всём правилам, с выгрузкой базы после каждого апа (каждая выгрузка минимум 1.5 часов, тестовый сервер не самый быстрый), ещё 1-2 недели на проверку расширений другими разработчиками исправление, если надо (кроме 1с у них есть и другая работа), после этого обновление рабочей в выходные (работу базы нельзя остановливать на целый день), если есть проблема - надо ждать следующих выходных, после этого ещё неделя-другая на выявление ошибок и, если нужно, * назад (к счастью пока не было такого). Тч 2 недели до нового года - это очень мало для нормального обновления базы. Потенциально время можно было существенно уменьшить, если не было поднятия релиза - меньше вероятности крупных изменений, требующих изменений в расширениях. Но не судьба, это изменение похоже в последней версии добавлено - придётся подвинуть другую работу (под конец года её много и без этих внезапных хотелок от пользователей), забыть про выгрузку после каждого апа и молиться, чтобы никакой из апов не сломал базу и не пришлось всё заново делать.
(7) Для восстановления базы, если очередной ап сломает базу. Хранилище конфигураций не использую (конфигурация не снята с замка, не вижу пока в этом смысл), и, насколько я понимаю, хранилище конфигурации не поможет, если база сломается во время обновления данных, например, из-за отключения эл-ва.
(12) ИБП - это источник бесперебойного питания? Не знаю, есть ли он у серверов, скорее всего нет или они не помогли, у нас как-то в городе вырубило электричество, системщики потом несколько дней восстанавливали сервера...
Накатку апов на пустую базу можно и без хранилища сделать , но мне раньше советовали так не делать, вроде при обновлении таким способом много ошибок возникает - это уже пофиксили? Таким способом, наверное, будет побыстрее.
Накатку апов на пустую базу можно и без хранилища сделать , но мне раньше советовали так не делать, вроде при обновлении таким способом много ошибок возникает - это уже пофиксили? Таким способом, наверное, будет побыстрее.
(14)
Да. Эко у вас все сложно.....
Не понимаю, про какое множество ошибок при обновлении пустой базы идет речь, поэтому не могу сказать, пофиксили это или нет.
ИБП - это источник бесперебойного питания?
Да. Эко у вас все сложно.....
Накатку апов на пустую базу можно и без хранилища сделать , но мне раньше советовали так не делать, вроде при обновлении таким способом много ошибок возникает - это уже пофиксили?
Не понимаю, про какое множество ошибок при обновлении пустой базы идет речь, поэтому не могу сказать, пофиксили это или нет.
(16)
И если перескочить требуемый релиз, то можно тупо потерять данные, которые в новом релизе перенесли в другое место, а старое удалили.
Не понимаю, про какое множество ошибок при обновлении пустой базы идет речь,
Тут видимо про промежуточное обновление самих данных при переходах от релиза к релизу.
И если перескочить требуемый релиз, то можно тупо потерять данные, которые в новом релизе перенесли в другое место, а старое удалили.
(17) 1С хранит некую историю изменений, если не скакать через много версий, то вполне можно обновляться.
Последний такой случай на моей памяти был с УТ11, когда с какой-то версии решили переделать единицы измерений и там "старый" справочник удалили чуть ли не в следующей версии.
Последний такой случай на моей памяти был с УТ11, когда с какой-то версии решили переделать единицы измерений и там "старый" справочник удалили чуть ли не в следующей версии.
(18)
Просто многие думают, что если они на чистой базе прогонят всю цепочку обновлений конфигурации, то потом можно будет готовый CF-результат тупо накатить на боевую. И вот тут то может поджидать сюрприз.
Поэтому если между боевой базой и последним обновлением есть вот такие разрывы в таблице последовательности обновлений - то для гарантии придется боевую базу обновлять итерационно по крайним поддерживаемым релизам.
1С хранит некую историю изменений, если не скакать через много версий, то вполне можно обновляться.
Ну да, я про то же. Именно для этого и существует таблица применимости апдейтов.
Просто многие думают, что если они на чистой базе прогонят всю цепочку обновлений конфигурации, то потом можно будет готовый CF-результат тупо накатить на боевую. И вот тут то может поджидать сюрприз.
Поэтому если между боевой базой и последним обновлением есть вот такие разрывы в таблице последовательности обновлений - то для гарантии придется боевую базу обновлять итерационно по крайним поддерживаемым релизам.
(10) Тут больше проблема с новыми налоговыми ставками, которые нужны для заведения договоров (я, похоже, забыла дописать про это в вопросе). Должны появиться новые значения в перечислении, а на основе них идут некоторые расчёты в расширении и эти расчёты уже должны быть доступны с нового года.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот