Обновление Бухгалтерии 3.0, в состоянии расхождения объектов по внутренним идентификаторам

05.10.17

–

Обратился клиент с измененной Бухгалтерией 3.0. При сравнении с базой поставщика, через Поддержка-Настройка поддержки, дает значительный разбег конфигураций - примерно 40% измененных объектов + 20% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".

База Бухгалтерии 3.0 - клиенту известно, что изменения есть, но их не должно быть много, касаются нумерации некоторых документов.

При сравнении с базой поставщика, через Поддержка-Настройка поддержки, дает значительный разбег конфигураций - примерно 40% измененных объектов + 20% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".

Однако, при сравнении с файлом (конфигурация поставщика выгружена в файл) - фактических различий в конфигурациях 1-2%.

Видимо в какой-то момент обновляли путем сравнение-объединение с файлом конфигурации поставщика - как в свое время делалось в 7.7 - и все новые объекты получили свои новые внутренние идентификаторы и не соотносятся с аналогичными в типовой.

Цель в идеале - вернуть конфу к виду, когда обновление через Поддержка-Обновить реально и обозримо по времени, оставив нужные изменения конфигурации и сохранив данные базы, а также закрыть "под замок" типовые объекты.

Объясняю, почему нельзя просто загрузить типовую конфу - теряем данные, сохраненные в тех объектах, которые разъехались по идентификаторам - их просто затрёт.

В данном примере повезло - кривое обновление базы не затронуло серьёзных объектов, содержащих данные - в основном макеты, формы, отчеты, обработки, модули . Но сначала это было не явно - присутствовали и регистры, и константы, и документы.

Опишу этапы, по которым действовала, может, кому поможет, кого-то наведет на мысль .

1. Сравнить, обновить - с конфигурацией поставщика - через Поддержку - объединять ставим: макеты, формы, отчеты, обработки, картинки и т.п - все объекты, которые не хранят информацию и в которых нет "ручных" изменений. После такого объединения получаем удвоенные объекты - проходим по ним и удаляем те, которые "сняты с поддержки" - это как раз те, которые добавлялись в конфу со своими нетиповыми идентификаторами. При удалении предупреждает о ссылках на эти объекты - заменяем их ссылками на типовые объекты в объектах, в модулях ничего не меняем.

2. В базе данных проверяем объекты, которые хранят информацию и "разъехались" с типовой - есть ли в них информация.

В моем случае несказанно повезло: 3 регистра, 2 константы и 1 вид документа оказались не использованы - данных по ним не было и сохранять не нужно было - с ними я поступила аналогично 1 пункту.

В общем случае, когда данные есть - путей 2: либо эти объекты так и оставляем - "разъехавшимися" и каждое обновление обновляем их индивидуально, либо сохраняем "старый" объект с данными под другим именем и готовим обработку по переносу данных из него в типовой объект - переносим и удаляем "старый" объект.

Итого получаем конфигурацию более приближенную к типовой - в которой оставлены только нужные изменения.

3. При обновлении на следующий релиз через Поддержка-обновление на форме настройки поддержки указываем, что "новые объекты" - "не редактировать", "идентичные объекты" - "не редактировать". Так мы вернем "под замок" объекты, которые не отличаются от типовых.

обновление

–

См. также

Обновление для КА 1.1, ЗУП 2.5, БУХ 2.0: НДС, ЕФС-1, Расчет страховых взносов, Мобилизация, Статистика, Электронные трудовые книжки, 2-НДФЛ, Регламентированная отчетность, Кадровый учет, Прослеживаемость импортных товаров

Зарплата Регламентированный учет и отчетность Кадровый учет Обновление 1С Платформа 1С v8.3 Сложные периодические расчеты 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Зарплата и Управление Персоналом 2.5 Бухгалтерский учет Налоговый учет Управленческий учет Акцизы ЕНВД ЕСН Земельный налог ИП, ПБОЮЛ, КФХ Налог на имущество Налог на прибыль НДС НДФЛ ФОМС, ЕФС Транспортный налог УСН ПСН (патентная система налогообложения) Платные (руб)

Обновления для конфигураций: КА 1.1; ЗУП 2.5; БУХ 2.0; КА 1.1 Комплексная автоматизация торговли алкогольной продукцией; КА 1.1 Комплексный учет сельскохозяйственного предприятия

19900 руб.

01.04.2020 141126 682 352

233

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019 24382 55 VPanin56 26

Ссылочная константа содержит недопустимый ссылочный номер таблицы

Обновление 1С Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Россия Бесплатно (free)

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Сегодня расскажу, как решить одну из проблем, с которой можно столкнуться при обновлении конфигурации 1С.

19.03.2024 1009 sergey.skirdin 4

Информирование по почте о выходе обновления для текущей версии конфигурации

Обновление 1С Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Абонемент ($m)

Внешняя обработка, которая выявляет и уведомляет о выходе обновления для вашей текущей версии конфигурации.

1 стартмани

05.02.2024 489 5 user702253_sokotov.vso 1

Скрипт для обновления базы с расширением из хранилища

Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Небольшая оптимизация рабочего времени через скрипт обновления базы 1С с расширением из хранилища конфигураций.

22.01.2024 1224 ke.92@mail.ru 3

Многопоточное обновление 1С: Управление холдингом

Обновление 1С 8.3.14 1С:Управление холдингом Абонемент ($m)

Что делать, если обновление базы в режиме предприятия выполняется значительно больше вашего технологического окна, даже если это окно - с вечера пятницы и до утра понедельника.

1 стартмани

10.01.2024 3275 saver77 18

Не обновляется типовая конфигурация 1С через конфигуратор

Обновление 1С Платформа 1С v8.3 Россия Бесплатно (free)

Столкнулся с проблемой. Нужно было поднять до текущего релиза Розницу 2.3. Обновлял по старинке, через конфигуратор (база клиент-серверная). Указывал логин и пароль, ждал скачивания обновления и обновлял. Но после накатывания 5 релизов следующий устанавливаться не хотел, а точнее конфигуратор гордо говорил, что обновлений больше нет. Решение нашел здесь на форуме и хочу зафиксировать. Чтобы самому не забыть и передать опыт начинающим.

29.11.2023 1495 shestopalovpro 4

Принудительный запуск дополнительных процедур обработки данных после обновления

Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Ручной запуск процедур обработки обработчиков после обновлений. Может быть полезно стажерам, консультантам, разработчикам, администраторам, всем, кто обновляет информационные базы.

1 стартмани

20.11.2023 691 9 IvanTerentev 0

Отзывы

5. motorkuzbassa.it 99 05.10.17 14:44 Сейчас в теме

все намного проще. ..
1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку с текущим .cf поставщика (который можно тут же и выгрузить), вернет всем объектам родные уиды. т.к. сравнение идет по именам объектов. а все дописи соттветственно в лице реквизитов новых останутся.
2. сравнить с измененной конфой на предмет изменений модулей и форм...радоваться..

Остальные комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. slawa 26 05.10.17 13:00 Сейчас в теме

Видимо в какой-то момент обновляли путем сравнение-объединение с файлом конфигурации поставщика - как в свое время делалось в 7.7

Сравнение-объединение в 8-ке переносит реквизиты вместе с их внутренними идентификаторами.
Скорее всего объекты, из новой конфигурации поставщика, переносили с помощью Ctrl+C - Ctrl-V

3. nvv1970 05.10.17 14:23 Сейчас в теме

(1)

Сравнение-объединение в 8-ке переносит реквизиты вместе с их внутренними идентификаторами.

Откуда информация? 1с говорит об обратном.
Если например в хранилище добавить новый объект и потом сравнить/объединить цф с рабочей, то новый объект будет с новым, отличающимся от хранилища, идентификатором. Так же новым будет имя таблицы в СУБД, но не об этом речь.
Соответственно следующее сравнение цф будет более долгим, т.к. по ГУИДу объект не будет найден и будет произведен поиск по ИМЕНИ для сопоставления.
Как-то так.
А вот при полной замене цф все идентификаторы будут заменены на те, что в файле цф.

9. slawa 26 06.10.17 01:36 Сейчас в теме

(3)

Откуда информация? 1с говорит об обратном.

Из личного опыта.

Создайте базу с одним справочником, выгрузите ЦФ
Создайте еще одну базу с одним справочником (лучше с другим именем, чем в первой), сравните и объедините в нее ЦФ от первой базы
Разберите конфигурации на файлы и посмотрите там ГУИДы справочников.

Не путайте с наименованием таблиц и полей.

14. nvv1970 08.10.17 21:51 Сейчас в теме

(9) Есть на итс вот такая древняя статья.
В ней упоминание про древние релизы платформы. Но по существу скорости сравнения конфигураций воз и ныне там. Поэтому я склонен верить статье.

Действительно при сравнении конф и добавлении нового справочника uuid, которые мы видим в выгрузках конф в xml вроде как те же самые.
Это мы видим глазами. И то что видим - называем личным опытом. Вроде как не подкопаться.

Однако я так же вижу, что при групповой разработке, если рабочая (продакшн) база не подключена к хранилищу (обновляется ч/з сравнение/объединение), то после первого же добавленного нового объекта в хранилище сравнение начинает подтупливать. Чем больше новых объектов было добавлено после создания хранилища - тем больше тормозит сравнение. Из 10-20 сек сравнение может превратиться в 10-30 минут.
Есть еще интересная особенность... Если развернуть в тестовую базу бэкап обновленной рабочей базы и подключить ее к хранилищу (дефакто конфигурации будут в такой момент одинаковые), то конфигурация бэкапа заменится за конфигурацию хранилища. При последующем обновлении пройдет реструктуризация половины базы несмотря на фактическое отсутствие изменений. Никогда не расследовал что именно реструктуризируется, но предположу, что это именно новые объекты (созданные в процессе жизни хранилища). И еще замечу, что если рабочая база подключена к хранилищу разработки и из него обновляется через получение изменений, то такого эффекта нет.
Это тоже опыт. И даже не личный, а коллективный.
Возможно он не противоречит тому что мы видим в xml, а всего лишь говорит о том, что мы видим не все.

15. klinval 338 10.10.17 11:34 Сейчас в теме

(9)

Создайте базу с одним справочником, выгрузите ЦФ
Создайте еще одну базу с одним справочником (лучше с другим именем, чем в первой), сравните и объедините в нее ЦФ от первой базы
Разберите конфигурации на файлы и посмотрите там ГУИДы справочников.

Проверил, действительно гуиды равны. Но ещё поддержу (14): тоже работаем через хранилище и по ряду косвенных признаков, описанных в комментарии, видно что внутренние идентификаторы не равны. Плюс есть не древняя статья: Общие правила обмена объектами метаданных между конфигурациями. Там сказано:

Механизм: Объединение конфигураций.
Способ сопоставления: Сопоставление по имени. При отсутствии соответствия по имени – сопоставление по внутреннему идентификатору. Возможна ручная установка соответствия.
Поведение идентификатора при перемещении объекта: При копировании нового объекта изменяется. При объединении двух объектов, между которыми обнаружено соответствие, не изменяется.
...
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:

1. Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
2. Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
3. Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.

Правда есть ещё справка по 8.3.10:

По умолчанию при объединении конфигурации объекты, отсутствующие в основной конфигурации, добавляются в нее с теми идентификаторами, которые существуют у них в загружаемой конфигурации.

Установка флажка Режим копирования объектов... позволяет выполнять добавление новых объектов по правилам, существовавшим в предыдущих версиях платформы: при добавлении объектов, отсутствующих в основной конфигурации, для них всегда генерируются новые идентификаторы.

При нажатии кнопки ОК производится повторное сравнение с учетом выбранной настройки.

Я посмотрел старые созданные объекты - там идентификаторы одинаковые. Т.е. всё вроде одинаково, но как писали выше:

Есть еще интересная особенность... Если развернуть в тестовую базу бэкап обновленной рабочей базы и подключить ее к хранилищу (дефакто конфигурации будут в такой момент одинаковые), то конфигурация бэкапа заменится за конфигурацию хранилища. При последующем обновлении пройдет реструктуризация половины базы несмотря на фактическое отсутствие изменений.

Итого:
В ИТС информация разнится. Возможно раньше было создание объектов с новыми идентификаторами, а в какой-то версии начали создаваться беря идентификаторы из файла. Но даже с одинаковыми идентификаторами при подключении к хранилищу происходит реструктуризация.

17. slawa 26 12.10.17 01:56 Сейчас в теме

(15)

тоже работаем через хранилище и по ряду косвенных признаков, описанных в комментарии, видно что внутренние идентификаторы не равны.

Зачем гадать?
Ответил в (16)

18. klinval 338 12.10.17 10:16 Сейчас в теме

(17)

Все базы разобрал - ГУИДы везде одинаковые

Ранее я написал:

Я посмотрел старые созданные объекты - там идентификаторы одинаковые.

Не совсем подробно описал: это я сверял самый первый новый объект, созданный в хранилище, с рабочей базой. В рабочую добавляем через "Сравнить/объединить". Гуид оказался одинаковым. Так что я подтверждаю, что они равны...

Но, это не отменяет того факта, что при подключении к хранилищу свежей базы происходит массовая реструктуризация (хотя конфигурации равны). Я не знаю чем это объяснить, т.к. если нет изменений, то зачем реструктуризировать данные? Добавилась какая-то служебная информация для конфигурации (чтобы функционировать в хранилище), но данные то тут при чём? При обновлении и то меньше реструктуризируется, чем при подключении к хранилищу!

Плюс в ИТС в двух местах прямо написано, что при сравнить/объединить гуиды не должны быть равны, а в одном косвенно указывают на то, что должны копироваться.

16. slawa 26 12.10.17 01:54 Сейчас в теме

(3)

Если например в хранилище добавить новый объект и потом сравнить/объединить цф с рабочей, то новый объект будет с новым, отличающимся от хранилища, идентификатором.

Проверил:

Сделал базу Рабочая с одним справочником
Скопировал .1сд файл Рабочей в две базы Хран1 и Хран2
Из Хран1 создал хранилище конфигурации
Подключил Хран2 к хранилищу.
В Хран2 добавил новый справочник. Закоммител изменения.
Получил изменения в Хран1
Выгрузил ЦФ из Хран1
СравнилИОбъеденил ЦФ с Рабочей базой

Все базы разобрал - ГУИДы везде одинаковые

2. klinval 338 05.10.17 14:09 Сейчас в теме

1. Справка - О программе - Версия конфигурации
2. Конфигурация - Поддержка - Настройка поддержки - Версия
Эти две версии совпадали до ваших действий?

Пробовали играться с настройкой "Установить соответствие объектов" при сравнении/объединении с конфигурацией поставщика? Может это будет правильным решением вашей проблемы?

4. klinval 338 05.10.17 14:42 Сейчас в теме

готовим обработку по переносу данных из него в типовой объект

В старой базе объект называется так-же. Через типовую 1С-овскую загрузку/выгрузку в xml просто переносим из старой базы все данные.

5. motorkuzbassa.it 99 05.10.17 14:44 Сейчас в теме

6. klinval 338 05.10.17 15:31 Сейчас в теме

Сейчас провёл эксперимент:
Типовая БП КОРП. Создал копированием второй справочник "Банки". Перевёл все ссылки/подписки на него. Первоначальный "Банки" снял с поддержки и удалил. Убедился что сравнение объединение мой "Банки" с типовым "Банки" не соотносит.
Снял базу с поддержки. Сделал "Сравнить/объединить" с предварительно выгруженным Cf-ником типовой. Поставил на поддержку. У "Банки" появился "замок". Данные из него не пропали и теперь сравнение с типовой через поддержку не видит в нём различий.

Поэтому поддерживаю (5) комментарий - на практике попробовал: правильный способ описан, лучше чем в статье!

7. Vladimir Litvinenko 2872 05.10.17 19:57 Сейчас в теме

(5)

Более того, этот способ можно применять для целенаправленного снятия с поддержки конфигураций подключенных к хранилищу при сохранении возможности обновляться на следующие релизы.

Если баз для тестирования и разработки много, а конфигурация большая, например ERP , то за счет исключения конфигурации поставщика из каждой базы получается значительная экономия дискового пространства, особенно если базы для разработки не являются копиями типовых конфигураций, а являются демо-базами с небольшим объемом данных. Также это полезно для ускорения синхронизации хранилища с Git-репозиторием и уменьшения объема самого репозитория.

Перед обновлением на новый релиз достаточно поставить на поддержку одну из баз через сравнение-объединение с CF-файлом текущего релиза. После чего можно переходить на новый релиз через механизм поддержки.

Есть только одна тонкость. Не все объекты могут быть сразу поставлены на поддержку автоматически после объединения с CF-файлом текущего релиза. Для того чтобы поставить на поддержку все типовые объекты нужно зайти в настройку поддержки, выбрать для корня конфигурации правило "Редактируется с сохранением поддержки" и поставить флаг рекурсивной установки этого правила для подчиненных объектов.

Также этот способ имеет смысл применять только если в компании принят стандарт наименования добавленных в конфигурацию новых объектов. Например их префиксация или постфиксация. Ведь при снятии с поддержки теряется визуальная идентификация типовых объектов.

8. julorl 15 05.10.17 22:44 Сейчас в теме

(5)
В первый раз столкнулась с такой ситуацией, сравнение измененной и типовой резало глаз, список изменений уходил в даль.
В помощь не нагуглила ничего ценного.
Как я вышла из ситуации описала в статье - если есть лучший способ - прекрасно, в другой раз конечно его использую.
Спасибо.

10. motorkuzbassa.it 99 06.10.17 08:57 Сейчас в теме

(8) Спасибо, закрыли пробел для будущих поколений...)... сделал в помощь..

Быстрый способ сохранить свое бесценное время... Первопричины: При сравнении с базой поставщика, через Поддержка-Настройка поддержки, дает значительный разбег конфигураций - примерно 40(100500)% измененных объектов + 20(100500)% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".
Рецепты:

Основной:

1.Снять с поддержки и "сравнить объединить.."с постановкой на поддержку..." с текущим .cf поставщика (который можно тут же и выгрузить. Важно: при расхождении номеров версий конфигураций основной и поставщика, конечно нужно найти/использовать релиз поставщика, именно с номером основной конфигурации), вернет всем объектам родные уиды и замки. т.к. сравнение идет по именам объектов. а все дописи соответственно в лице реквизитов новых останутся.
2. сравнить с измененной конфигурацией(которую можно тут же и выгрузить) на предмет изменений модулей и форм, привести в соответствие, необходимые изменения...радоваться..

11. julorl 15 06.10.17 12:43 Сейчас в теме

(10)
но насчет "сравнение идет по именам объектов" часто в версиях имена и объектов и общих модулей и форм меняются.

12. motorkuzbassa.it 99 06.10.17 13:49 Сейчас в теме

(11)так мы же текущую конф.основную ставим на поддержку на текущую.поставщика. где ж там будут такие изыски...а не сразу летим на самый крайний..)..рекомендую именно с этого начать..), т.е. релизы ставим номер в номер..