Обновление изменённой типовой конфигурации 1С 8.2/8.3

30.12.15

База данных - Обновление 1С

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

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


ЛЮБОЕ обновление конфигурации начинается с выгрузки ИБ. Это "золотое правило", это надо помнить всегда, это надо делать при любом методе (даже если там про это забыли сказать). Далее, можно пойти двумя способами: либо обновлять в тестовой базе, либо обновлять в рабочей базе. Тут важный момент в следующем: обычно изменённые конфигурации обновляют не на каждый релиз (как это можно легко делать с типовыми), а сразу на несколько, поскольку этот процесс трудозатратный. В первом способе (обновлять на тестовой базе) - предполагается итоговый перенос обновления на рабочую базу через загрузку cf-файла. В этом случае могут произойти ошибки, связанные с удалёнными реквизитами (об этом можно найти множество статей). Стало быть - есть некоторые риски, но зато во время обновления (которое может занять целый день и даже дольше), пользователи могут спокойно работать, изменяя базу данных. Во-втором способе (обновлять на рабочей базе) - эти риски исключены, но на всё время обновления ключевые пользователи не смогут работать в этой базе. В форумах есть достаточно обсуждений, какой метод чем хорош и стоит-ли переносить обновление через файл конфигурации. Могу лишь сказать: исходя из опыта работы по первому способу, подобных ошибок не случалось при загрузке cf-файла. В любом случае - по бэкапу можно восстановить базу. Здесь будет рассматриваться именно первый способ, но на суть метода это не влияет и при желании можно действовать по второму способу, используя предложенный метод.


Итак - развернув тестовую базу по свежему бэкапу, производим последовательные обновления релизов до последнего. После каждого релиза запускаем "Отладку", для сохранения изменений в конфигурации и реорганизации данных. Во всех диалоговых окнах жмём ОК/Далее/Принять/Да/Продолжить...

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


1. Сохраняем в текстовых файлах изменения конфигурации ДО и ПОСЛЕ обновления. Открываем в режиме Конфигуратора рабочую и тестовую базы. Открываем в них конфигурации. И в обеих базах запускаем обработку сравнения конфигурации ("Конфигурация - Сравнить конфигурации..."). ВАЖНО: в обеих базах одинаково выбирать конфигурации:

Далее, в окне результата сравнения кликаем правой кнопкой мышки по названию конфигурации (самая верхняя строка), выбираем "Отчёт о сравнении объектов..." и сохраняем в виде текстового файла:

 

 

Причём сохраняем следующим образом: в рабочей базе (где конфигурация ДО обновления) - в файл с окончанием "old", а в тестовой базе (где конфигурация ПОСЛЕ обновления) - в файл с окончанием "new".


2. Внесение утерянных изменений в обновлённую конфигурацию. Переходим к ключевому этапу метода. Поскольку это основной пункт, то для небольшого пояснения происходящего немного мат.части. На платформе 1С 7.7 файл обновления представлял собой полную конфигурацию. И обновление в 1С 7.7 заключалось в загрузке новой конфигурации и реорганизации базы данных под эту конфигурацию. Таким образом, и конфигурация, и обновление по сути были одним и тем же md-файлом.  В отличии от платформы 1С 7.7, на платформе 1С 8.x: конфигурация передаётся через cf-файл, а обновление - через cfu-файл. Отличие этих файлов в том, что cf-файл содержит все объекты конфигурации, а cfu-файл - только те, которые изменяются данным обновлением. И, таким образом, при обновлении на платформе 1С 8.x затрагиваются только те объекты конфигурации, которые реально изменились в новом релизе. В результате, если такой объект изменялся нами, то после обновления он полностью заменится на типовой, и нам будет необходимо повторить в нём те изменения, которые были у него до обновления так, чтобы этот объект содержал и наши изменения, и изменения нового релиза, одновременно. Но зато если изменённый нами объект конфигурации не затрагивался обновлением - в нём останутся наши изменения после обновления. Чтобы проще это понять - изображу это в виде схемы:

Рис. 3: Перенос изменений в обновлённую конфигурацию

На данной схеме изображена некоторая типовая конфигурация в процессе изменения и обновления. Строки - это её объекты (документы, справочники, обработки и так далее). Сначала (под номером I) - это просто типовая конфигурация: все объекты без каких-либо изменений. Потом, под номером II, мы уже видим типовую изменённую конфигурацию: некоторые объекты были изменены и эти изменённые объекты обозначены красным цветом. Под номером III - это очередное обновление для типовой конфигурации: по сути оно содержит только затронутые изменениями нового релиза объекты, которые обозначены зелёным цветом, но для наглядности я дорисовал и все остальные объекты. И нам требуется получить обновлённую типовую конфигурацию (изображённую на схеме I), но с изменениями и схемы II, и схемы III. На данном примере - эта конечная конфигурация изображена под номером IV и содержит один объект, который был изменён и нами, и обновлением. Остальные изменённые нами объекты, очевидно, остались нетронутыми данным обновлением. Теперь вопрос: как внести ВСЕ наши изменения в объект, который был затронут обновлением? Очевидно, что нам надо сделать два шага: во-первых, отыскать этот объект, а во-вторых - найти в нём места, где должны быть наши изменения и внести их заново. Замечу, что, естественно, таких объектов может быть несколько и требуется их всех найти и исправить. Итак, приступим к этому последнему этапу обновления. На данный момент, у нас должна быть открыта тестовая база в режиме Конфигуратора. Если там ещё открыт результат обработки сравнения конфигураций или ещё какое-нибудь окно - закроем их всех, чтобы не путаться. Далее - мы открываем рабочую базу в режиме Конфигуратора (на время обновления тестовой базы можно было закрыть её) и запускаем там сравнение конфигураций. И описание последних двух шагов (найти и исправить) я помещу в отдельные подпункты:


2.1. Поиск объекта, с затёртыми обновлением изменениями. Самое время вспомнить про txt-файлики с окончаниями old/new. На самом деле, в этих файлах отражены все изменения конфигурации (относительно типовой) ДО и ПОСЛЕ обновления соответственно. Таким образом, если мы какое-то изменение затёрли обновлением, то оно будет только в файле "ОтчетОСравнении_old.txt". То есть - поиск необходимых объектов конфигурации сводится к сравнению этих двух файлов. Сравнивать эти файлы мы будем с помощью файлового менеджера Total Commander и его встроенных инструментов. Думаю, что здесь не нужно пояснять, что такое Total Commander, где его брать и как им пользоваться... Тем не менее, требуемые этапы его применения здесь кратко буду описывать. Итак, запускаем Total Commander. Если язык интерфейса английский (главное меню и так далее), то можно сменить на русский: "Configuration - Options...", в диалоговом окне выбираем в левом столбике раздел "Language", в списке ищем/выбираем "Russian (Русский)" и жмём "OK". Далее, через Total Commander ищем txt-файлы отчётов, выделяем их ("Insert" или "правым кликом мышки") и запускаем сравнение файлов: "Файлы - Сравнить по содержимому..." (в английском интерфейсе: "Files - Compare By Content..."). В открывшемся окошке слева/справа отображается соответственно содержимое файлов, кнопки "Следующее отличие"/"Предыдущее отличие" позволяют искать различия. Этот инструмент позволит быстро найти интересующие нас объекты.

Рис. 4: Сравнение изменений конфигураций ДО и ПОСЛЕ обновления

Замечание: может случиться и обратная ситуация - в конфигурации ПОСЛЕ обновления появились различия, которых не было ДО обновления. Это означает, что релиз обновления удалил из конфигурации соответствующие объекты. В принципе, эти объекты можно просто пропускать в наших исправлениях, поскольку в этих объектах не было изменений.


2.2. Внесение изменений в обновлённые объекты. После того, как мы нашли объект с затёртыми изменениями, надо определить, где именно были эти изменения: в модуле (программном тексте), диалоговом окне (на форме) или иных настройках. Здесь я буду разделять два случая: изменение в модуле и все другие изменения. И рассмотрим эти два случая отдельно.


2.2.1. Затёртые обновлением изменения были в модуле. На самом деле, это основной случай (такое встречается намного чаще) и этот случай как раз в нашем примере: изменение удалились в модуле "УчётНДС". Как выше мы уже напоминали, что в Конфигураторе рабочей базы у нас открыто окно сравнения конфигураций. Ищем там необходимый нам объект. На самом деле, его положение в дереве конфигурации описано в нашем текстовом файле, а именно: "ОбщийМодуль.УчетНДС.Модуль". Именно так и ищем в окне сравнения. Разворачиваем дерево подчинённостей пока не найдём нужный модуль - с левого края напротив него должен быть зелёный карандаш, показывающий, что объект изменён по сравнению с конфигурацией поставщика. По найденной строке кликаем правой кнопкой мышки и выбираем "Показать различия в модулях...":

Рис. 5: Показать различия в модулях.

После этого откроется окно сравнения модулей:

Рис. 6: Сравнение модулей.

Здесь, в верхней части указаны процедуры и функции, в которых имеются изменения (в нашем случае - это одна процедура "ВывестиСчетФактуруВТабличныйДокумент"), а в нижней части - тексты выбранной процедуры или функции с выделенными изменениями. Нам нужно эти изменения перенести в нашу тестовую базу. Но при этом не удалить изменения от обновления. Автоматизировать это можно следующим образом. Устанавливаем курсор в левую нижнюю часть (где текст выбранной процедуры с нашими изменениями) и жмём последовательно Ctrl+A (выделить всё) и Ctrl+C (копировать выделенное в буфер). Затем создаём файл с условным названием "old_izm.txt", открываем в текстовом редакторе и жмём Ctrl+V (вставить содержимое буфера). То же самое делаем для правой нижней части (где текст выбранной процедуры из типовой конфигурации необновлённого релиза) - в результате создаём файл с условным названием "old_type.txt". После этого переходим в Конфигуратор тестовой базы (он должен быть открыт рядом, но без каких-илбо окон внутри, чтобы не путаться в этих двух конфигураторах) - и в конфигурации ищем наш модуль (в данном примере это "ОбщийМодуль.УчетНДС.Модуль") и в нём необходимую процедуру (в данном примере это "ВывестиСчетФактуруВТабличныйДокумент"): выделяем её всю и копируем в новый текстовый файл с условным названием "new_type.txt". Таки образом, у нас появилось три файла ("old_izm.txt", "old_type.txt", "new_type.txt"), на основе которых нам нужно создать четвёртый файл - "new_izm.txt". В этом четвёртом файле как раз должны содержаться наши изменения, но с учётом обновления. Его мы будем формировать последовательно сравнивая имеющиеся три файла. Для начала определим, имеются-ли в этой процедуре следы изменений обновления? Для этого мы сравниваем через Total Commander (см. выше) файл "old_type.txt" и "new_type.txt". Если сравнение показало, что файлы идентичны или различие в количестве пробелов или знаков табуляции - это значит с этим куском изменений нам повезло и перенести изменения можно просто скопировав содержимое файла "old_izm.txt" и вставив в открытый модуль тестовой базы, удалив перед этим соответствующую процедуру (проще говоря - заменив её). Тут важно аккуратно следить за пробелами до и после процедуры, чтобы не было лишнего в дальнейшем сравнении: на функциональность это, конечно, не повлияет, но слегка затруднит проверку. Если же сравнение "old_type.txt" и "new_type.txt" показало, что есть реальные различия - это означает, что в этой процедуре имеются как наши изменения, так и изменения обновления. Чтобы упростить задачу переноса: сначала можно визуально оценить, каких изменений больше - от обновления или наших. Для этого опять же через Total Commander последовательно сравниваем "old_type.txt" с "new_type.txt" и "old_izm.txt". И смотрим, где изменений больше: в сравнении "old_type.txt" и "new_type.txt" или в сравнении "old_type.txt" и "old_izm.txt". Если изменений больше в первом сравнении (обновление сильнее изменило функцию), то легче исправлять файл обновлённый, внося наши изменения, то есть - изменяем "new_type.txt". Условно назовём это первый случай внесения изменений. Если изменений больше во втором сравнении (у нас было больше изменений), то легче исправлять наш файл, внося изменения обновления, то есть - изменяем "old_izm.txt". Условно назовём это вторым случаем внесения изменений. Теперь, как именно быстро и точно перенести изменения. Для этого мы создаём четвёртый файл и, как уже договаривались, называем его "new_izm.txt". С учётом оптимизации переноса исправлений, копируем в этот файл содержимое либо "new_type.txt", либо "old_izm.txt" (соответственно, для первого или второго случая внесения изменений).
Теперь открываем сразу два окна сравнения файлов. Для первого случая внесения изменений - это сравнения для файлов "new_izm.txt"/"old_izm.txt" и "old_type.txt"/"old_izm.txt". Для второго случая - это сравнения файлов "new_izm.txt"/"new_type.txt" и "old_type.txt"/"new_type.txt". В окне сравнения есть кнопка "Редактирование": нажмём её в сравнении первой пары. Теперь поясним, что мы видим. В первой паре сравнения видны объекты и от нашего изменения, и от обновления. В соответствии, какой у нас случай, нам надо перенести изменения только наши, либо только обновления. Во втором окне сравнения - как раз видны только те изменения, которые мы должны перенести. Если обратить внимание - в обоих случаях, второй файл и первого, и второго сравнения - один и тот же. Поэтому мы ориентируемся на строки в этом файле, и по строкам во втором сравнении, вносим изменения в окне первого сравнения: нажатая кнопка "Редактирования" как раз позволит нам это сделать.

Для "наглядности" изобразим графически действия при переносе в первом случае (изменяем обновлённый файл, внося наши изменения):

Рис. 7: Перенос изменений

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

Самый сложный и неприятный случай - когда наши изменения и изменения обновления - в ОДНОМ месте. То есть реально на одном сегменте кода были два изменения. В таком случае требуется вмешательство программиста. Так же вмешательство программиста, но в меньшей степени, требуется, если, например, обновлением изменены имена переменных, которые используются в наших изменениях. Стоит заметить так же, что в файле "old_type.txt", либо "old_izm.txt" могут быть пустые строки - это "следа" наших изменений. Переносить надо так, чтобы в конечном файле их не было. На функциональность это не влияет, но в дальнейших сравнениях (при последующих обновлениях) - это немного затруднит анализ действий. Итак, после того, как мы сформировали четвёртый файл, перенеся все изменения - надо его содержимое скопировать в конфигурацию. В Конфигураторе тестовой базе, должен быть открыт нужный модуль на новом месте: удаляем существующую процедуру и вставляем содержимое нашего конечного файла, с учётом всех пробелов между предыдущими/последующими функциями. Таким образом мы перенесли изменения ОДНОЙ процедуры найденного объекта. У нас (рис. 6) эта процедура действительно одна. Если таких процедур несколько - описанные действия надо проделать для каждой. Если процедура новая (только в левой половинке) - то просто добавить её в соответствующий модуль в тестовой базе (для корректности дальнейшего сравнения - нужно сохранить порядок процедур, как в соответствующем модуле рабочей базы, где ещё старый релиз).


2.2.2. Затёртые обновлением изменения были НЕ в модуле. Для переноса таких изменений подобное сравнение никак не упростит работу, поэтому переносятся изменения просто визуальным сравнением объектов в рабочей и тестовой базах.

Таким образом - переносим изменения для каждого объекта, где наши изменения затёрлись обновлением. Чтобы проверить, насколько мы верно перенесли все изменения - сохраняем конфигурацию в тестовой базе, выгружаем сравнение конфигураций в файл "ОтчетОСравнении_new2.txt" и сравниваем с файлом "ОтчетОСравнении_old.txt". Если всё идеально, то будет сообщение "Файлы идентичны". Если обновлением были удалены какие-то объекты - то при правильном переносе изменений будут видны только эти объекты в различии. Правильным будет если в сравнении будут видны только пробелы/пустые строки/табуляции, но в таком случае лучше это вычищать и добиваться сообщения "Файлы идентичны". Таким образом, после сохранения изменений в тестовой базе, выгружаем сравнение в файл и сравниваем с изменениями в старом релизе - повторяем это до тех пор, пока сравнение не покажет, что мы перенесли все требуемые изменения.


3. Переносим обновлённую конфигурацию из тестовой в рабочую базу. На предыдущих этапах мы обновили тестовую базу до последнего релиза, проверили и перенесли необходимые изменения и сохранили полученную конфигурацию. Теперь мы её выгружаем в cf-файл и загружаем в рабочую базу. Перед загрузкой - необходимо сделать копию рабочей базы и снять с поддержки конфигурацию. ВСЁ. Пользователи "бездельничали" только в начале, когда мы выгружали базу, и в конце, когда мы снова выгружали базу и загружали конфигурацию.


На этом обновление полностью завершено.

 

Оригинал статьи находится на сайте  get-prog.ru

Обновление изменённая конфигурация 8.2 8.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    140611    678    352    

232

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

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

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

2 стартмани

08.05.2019    24210    54    VPanin56    26    

26

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

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

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

19.03.2024    828    sergey.skirdin    3    

13

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

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

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

22.01.2024    1115    ke.92@mail.ru    2    

24

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

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

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

1 стартмани

10.01.2024    3177    saver77    18    

24

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

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

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

29.11.2023    1349    shestopalovpro    4    

7

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

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

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

1 стартмани

20.11.2023    599    6    IvanTerentev    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. softcom_1c 20 30.12.15 18:58 Сейчас в теме
Зачем же так сложно? Использовать "Поддержка/ Обновить конфигурацию" и анализировать расхождения нового релиза с текущей конфигурацией (зеленые карандашики и фильтр "дважды измененные" не просто так) - гораздо быстрее и проще.
soulsteps; fomstas; angur; CratosX; IgorS; fancy; alest; alexstav; Batman; Натц; mpudy; Infector; paybaseme; nbeliaev; 32ops; mrXoxot; echo77; +17 Ответить
2. get-start 25 31.12.15 07:57 Сейчас в теме
(1) softcom_1c, я "вырос" на конфигурациях семёрки и, соответственно, методы, к которым я привык, именно "от туда"... насколько я знал, варианты при обновлении в восьмёрке лишь "приоритетные" (либо одно изменение, либо другое). про анализ/сопоставление - не знал. спасибо за информацию, если оно так на самом деле: попробую/проверю
4. Torin 741 31.12.15 14:02 Сейчас в теме
(2) Не проще ли свою поставку сделать? И пусть будет конфигурации на поддержке у двух поставщиков!!!

"...Сравнивать эти файлы мы будем с помощью файлового менеджера Total Commander и его встроенных инструментов.."

А чем Сравнить файлы не устраивает?

8. get-start 25 01.01.16 22:13 Сейчас в теме
(4) Torin, "А чем Сравнить файлы не устраивает? "

во-первых - алгоритм сравнения у tc намного корректнее, чем у конфигуратора 1с. поэтому сравнения более удобно проводится (для понимания, в чём различия)... ну и во-вторых - сравнивая в 1с у нас нет возможности "слёту" переносить необходимые нам изменения...
12. get-start 25 06.01.16 16:21 Сейчас в теме
(1) softcom_1c, поскольку первый комментарий во многом определил последующие и стал "топовым", то подведу некое резюме в ответе на него... ознакомившись и учитывая комментарий (10) от Bassgood (спасибо за информацию) - получается, что 1С только начинает внедрять способ изменения при сравнении... то есть - только начиная с платформы 8.3.6 имеется возможность сравнивать/анализировать с редактированием (даже используя подключённые внешние программы). насколько это корректно/удобно - это надо ещё проверять на деле. до этого релиза платформы - можно было ТОЛЬКО сравнивать/анализировать, без возможности редактирования. причём - сравнение производилось алгоритмами 1С, которые сами по себе являются не совсем корректными, что приводит к достаточно сложным (для понимания и анализа) результатам сравнения... поэтому в принципе, если платформа ниже 8.3.6 - инструментами 1С не сделать того, что предлагается в данной статье. но даже имея указанную платформу (и выше) - статья имеет своё место быть, как алгоритм переноса изменений и альтернатива для "встроенного" варианта, если на платформе будут возникать какие-то проблемы с подобными обработками...
3. albert 568 31.12.15 11:15 Сейчас в теме
Это больше похоже на текст из серии "Вредные советы" !
Хотя бы изучили, какие уже материалы есть здесь http://infostart.ru/public/18562/ , http://infostart.ru/public/283282/ и т.п.
7. get-start 25 01.01.16 22:11 Сейчас в теме
(3) albert, по ссылкам - насколько я понял (1 января), там идёт настройка переноса с помощью замещения. то есть - так или иначе, либо изменения обновления полностью замещают изменения конфигурации, либо изменения конфигурации полностью замещают изменения обновления. то есть - в том сравнении НЕТ возможности редактировать модуль. мой способ (с помощью Total Commander-а) предполагает эту возможность. поэтому - ничего вредного тут не вижу. наоборот - сплошная польза!
10. Bassgood 1425 03.01.16 12:27 Сейчас в теме
(7) с версии 8.3.6 можно вносить изменения в модули прямо во время их сравнения/объединения + возможность использования других сторонних программ для сравнения
Shmell; CratosX; okulus; get-start; +4 Ответить
11. get-start 25 03.01.16 18:47 Сейчас в теме
(10) Bassgood, это хорошо... если у 1с с первого раза получилось всё корректно (подключение сторонних программ), то можно лишь оставить принцип сравнения, сильно упростив все механизмы... то есть - здесь предлагается способ и как инструмент - tc, за неимением встроенного... но тем не менее, насколько я слышал - в этой платформе (8.3.6) сильно всё изменилось и так просто даже на неё бывает не перейти (если имеются доработки в конфигурации)... поэтому многие даже не смогут протестировать эти нововведения в ближайшее время.
5. AlexeyPapanov 458 31.12.15 19:56 Сейчас в теме
очень запутанно для новичка. а для опытных сие бесполезно.
абзацы на весь экран вообще пугают.
simvol@s; Tarlich; +2 Ответить
6. МимохожийОднако 141 01.01.16 12:06 Сейчас в теме
Плюсанул за попытку. А кто читал комментарии - выйдет и на другие материалы.
9. get-start 25 01.01.16 22:23 Сейчас в теме
(6) МимохожийОднако, спасибо за плюс. поскольку этим способом я много успешно пользовался, то уверен, что он кому-то будет полезен тоже.
13. WKBAPKA 214 06.01.16 18:18 Сейчас в теме
Блииииин... сколько обновляю никогда не додумывался до такой ацкой сложности )))
vx_gas; IgorS; +2 Ответить
15. get-start 25 06.01.16 19:02 Сейчас в теме
(13) - (14) WKBAPKA, конечно, привычным методом всегда удобнее/быстрее - против этого не поспоришь... НО

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

2. данный метод никак не задействует внимание обычно подобные обновления требуют высокой степени внимательности и при такой монотонной работе это внимание может рассеиваться, что приведёт к ошибкам обновления. данный метод полностью алгоритмизирует действия в связи с этим (делай раз - делай два - ...) внимание можно не так напрягать и ошибки практически исключены.

3. данный метод возможно делать без "понимания происходящего" это сомнительное высказывание, но фактически кроме пары случаев (где описано, что возможно требуется вмешательство программиста) - перенос может делать любой человек, умеющий просто открывать Конфигуратор.

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

как-то так, например.
14. WKBAPKA 214 06.01.16 18:20 Сейчас в теме
хотя... хорошая статья. если клиент спросит: почему так дорого? сразу показываем эту статью, поднимаем указательный палец вверх, поправляя очки со словами... это вам не что либо как, а как либо что )
16. DrAku1a 1679 11.01.16 07:18 Сейчас в теме
0. Сделать бекап перед обновлением
1. Сохранить текущую конфигурацию (A)
2. Сохранить конфигурацию поставщика (Б)
3. Обновить конфигурацию*
4. Сохранить обновлённую конфигурацию поставщика (В)
5. Выполнить сравнение конфигураций: сравнить А и Б
6. Выполнить сравнение конфигураций: сравнить Б и В
7. Перенести из конфигурации А объекты, не измененные при обновлении (их нет в сравнении Б и В)
8. Для измененных объектов - проанализировать, что именно изменялось и продублировать изменения (как вариант - "попроцедурное" обновление).
* - настоятельно рекомендуется не обновлять сразу конфигурацию ИБ
Оставьте свое сообщение