1с обновить конфигурацию поставщика
На Инфостарте присутствует довольно большое количество хороших статей про обновление нетиповых конфигураций, как на поддержке, так и без. Надеюсь, что данная статья также будет полезна тем, у кого еще не достаточно опыта для обновления нетиповых конфигураций, особое внимание уделено обновлению нетиповых форм.
Рассмотрим обновление на примере нетиповой конфигурации УПП 1.3 находящейся на поддержке с возможностью изменения с релиза 1.3.61.2 на релиз 1.3.62.1. Так как конфигурация сама по себе довольно тяжелая, то это накладывает некоторые особенности, в частности, не всегда получается открыть в одном конфигураторе несколько окон сравнения конфигурации.
Для обновления я использую две одинаковые копии базы данных старого релиза. В одной из них выполняю подготовку *.cf для обновления, назовем ее, например, for_updating. Другая база остается не тронутой и служит только как вспомогательная, для сравнения конфигураций, назовем ее base. В принципе, в качестве вспомогательной может использоваться конфигурация рабочей базы.
В базе for_updating выполняем «Конфигурация» – «Поддержка» – «Обновить конфигурацию», в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
Нажать кнопку «Выполнить», на данном этапе нет пока необходимости что-либо смотреть, так как целью является лишь получение конфигурации поставщика нового релиза.
В процессе обновления может появиться окно «Неразрешимые ссылки», нажимаем «Продолжить». О причинах появления данного окна поговорим ниже.
Откроется окно «Настройка правил поддержки» - для новых объектов (верхний раздел) с обеих сторон ставим «Объект редактируется с сохранением поддержки», для существующих объектов поставщика (нижний раздел) во всех четырех местах ставим флаг «Сохранять текущий режим», нажимаем «ОК».
Произошло обновление основной конфигурации. Сама по себе основная конфигурация на данном этапе нам не нужна, цель – получение новой конфигурации поставщика. Поэтому основную конфигурацию не сохраняем, конфигурацию базы данных не обновляем.
Выполняем «Конфигурация» – «Поддержка» – «Настройка поддержки». В открывшемся окне выбираем «Сохранить в файл» и сохраняем в *.cf конфигурацию поставщика нового релиза.
Основная конфигурация в том виде, в котором она на данный момент имеется, нам не нужна. Закрываем конфигурацию. «Конфигурация» - «Закрыть конфигурацию». Отказываемся от сохранения изменений.
В конфигурации для сравнения base запускаем сравнение конфигурации поставщика (старый релиз) и конфигурации поставщика из файла (новый релиз).
Таким образом, мы увидим только те изменения, которые будут выполнены в конфигурации при обновлении на новый релиз.
В базе for_updating снова запускаем обновление конфигурации через поддержку «Конфигурация» – «Поддержка» – «Обновить конфигурацию», в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
При нажатии на кнопку «Фильтр» откроется окно «Настройка фильтров просмотра». В данном окне устанавливаем флаг «Показывать только дважды измененные свойства».
При обновлении без нашего вмешательства происходит следующее:
- - объект не изменен нами, изменен в новом релизе – обновляется из нового релиза;
- - объект изменен нами, не изменен в новом релизе – остается наш объект;
- - объект изменен нами, изменен в новом релизе – это и есть дважды измененный объект, если ничего не менять – он загрузится из нового релиза.
Таким образом, наиболее пристальное внимание следует уделить именно дважды измененным объектам, их и будем рассматривать.
В данном примере изменено несколько общих модулей, в том числе и общий модуль « УчетНДС ».
По умолчанию в окне обновления показаны отличия основной и новой конфигурации поставщика от старой конфигурации поставщика.
Если посмотреть различия конфигураций в общем модуле «УчетНДС», то мы увидим следующую картину:
Если же сравнить эти модули в базе для сравнения base , то картина будет другая:
Очевидно, что функции «СобратьДанныеДляПечатиИсправленияСчетаФактуры», «СобратьДанныеДляПечатиКорректировочногоСчетаФактуры» и прочие содержат наши доработки, но не меняются при обновлении, а значит, нет смысла тратить время на их просмотр и анализ.
Поэтому, выполняя по процедурное обновление с выделенных процедур и функций можно снять флаги:
Многие скажут, что увидеть отличия старой конфигурации поставщика от новой можно с помощью изменения настройки фильтров просмотра в текущем конфигураторе, не используя сравнение конфигураций в базе base .
Однако, как показывает практический опыт это не так, процедуры и функции все равно отображаются в окне сравнения модулей, даже при установленном фильтре «показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
Сделав не большое мысленное усилие, выявим дважды измененные процедуры и функции, только они будут нуждаться в доработках после процесса объединения. С данными процедурами и функциями нужно определиться, что легче:
- - либо взять процедуру или функцию из новой конфигурации поставщика и потом, после объединения, внести наши доработки;
- - либо снять флаг обновления, тем самым сохранив наши доработки, и уже потом добавить нужный код из конфигурации поставщика.
Объединение с приоритетом основной конфигурации и объединение с приоритетом новой конфигурации поставщика использую редко, в принципе и без использования данных режимов результат получится качественным.
После того как общие модули были проанализированы и у части процедур сняты флаги обновления, видим, что у модулей теперь установлен режим объединения – индивидуальная настройка:
Двигаемся далее. Среди дважды измененных объектов имеется форма элемента справочника «ОсновныеСредства». Прежде чем определиться обновлять ли данную форму из новой конфигурации поставщика, нужно выяснить, что по факту меняется при обновлении.
Для этого в базе base с помощью контекстного меню вызовем «Отчет о сравнении объектов…». В открывшемся окне должны стоять все флаги в группе «Объекты».
Мне нравится режим вывода отчета в табличный документ, когда различия показываются графически, но это дело вкуса.
В результате сравнения формы элемента справочника «ОсновныеСредства» видим, что изменения есть только в модуле формы , а изменений в диалоге формы в обновлении нет.
Но так как форма элемента попала в дважды измененные объекты, то наши доработки есть либо в диалоге формы, либо в модуле.
Выполнив аналогичное сравнение в базе for_updating можно увидеть, что доработки есть в диалоге формы.
Причина тому, добавление справочника «ОсновныеСредства» в план видов характеристик «СвойстваОбъектов». Если обновить форму элемента справочника «ОсновныеСредства» мы получим неразрешимые ссылки, о чем и будет свидетельствовать окно:
В данном случае самым лучшим вариантом будет не обновлять форму элемента справочника «Основные средства» и уже потом добавить необходимый код в модуль формы элемента. В этом случае окно «Неразрешимые ссылки» при обновлении появляться не будет.
Сделаем отступление и представим, что диалог формы элемента справочника «Основные средства» меняется при обновлении на новый релиз, тогда лучшим вариантом было бы обновление формы. Уже потом, после объединения, нужно было бы добавить в форму наши изменения, как в модуль , так и в диалог . Если в модуле много наших доработок и мало от поставщика, то после объединения можно полностью вернуть наш модуль и добавить изменения поставщика.
В этом случае в процессе объединения появилось бы окно «Неразрешимые салки». Вариантов выбора в данном окне два: 1) «Пометить все для объединения»; 2) «Продолжить».
На мой взгляд, правильнее выбирать «Пометить все для объединения».
В этом случае план видов характеристик «СвойстваОбъектов» будет добавлен как объект для объединения в дереве во вновь открывшемся окне «Обновление…»
Естественно, что после обновления в план видов характеристик «СвойстваОбъектов» нужно будет добавить наши изменения, сделать это лучше с помощью сравнения и объединения с текущей конфигурацией.
Рассмотрим, что произошло бы, если бы мы выбрали «Продолжить» в окне «Неразрешимые ссылки». В этом случае форма элемента справочника «ОсновныеСредства» стала бы новой, а план видов характеристик «СвойстваОбъектов» остался бы старым. В этом случае у нас затрутся изменения в диалоге формы элемента справочника, а именно на странице «СвойстваИЗначения», смотри рисунок ниже.
Данная проблема тоже не является не преодолимой, если конечно о ней не забывать.
Конечно, лучше всего стараться как можно меньше вносить изменений в диалоги форм , например, создавать реквизиты и кнопки на форме программно.
Многие вообще рекомендуют не менять типовые формы, а создавать их копии с нашими доработками и делать их основными. Мне данный вариант не нравится потому, что если поставщик добавил что-то в диалоге форме – на моей форме это не появится и мне придется делать добавления вручную, а изменений поставщика может быть гораздо больше, чем наших.
Отдельное внимание хотелось бы уделить по процедурному обновлению форм (часть процедур беру из конфигурации поставщика, а часть нет - индивидуальная настройка). Рассмотрим, как при данном режиме происходит обновление диалога формы в отличие от режима « взять из конфигурации поставщика ».
Пример не имеет отношения к данному обновлению конфигурации, но показателен, поэтому рассмотрим его.
В справочник «Контрагенты» добавлено несколько реквизитов, и они помещены на форму элемента.
При обновлении конфигурации на новый релиз через поддержку будет предложено окно сравнения и объединения конфигурации, в котором можно сделать различные настройки. Сравним несколько вариантов:
1. Флаг обновления формы выставлен, но обновление сделано по процедурно , т.е. по факту выполнена индивидуальная настройка
Многие думают, что диалог формы должен взяться из конфигурации поставщика, а процедуры в зависимости от сделанных настроек. Посмотрим, насколько это так после выполнения объединения. Сделаем сравнение конфигурации поставщика с основной конфигурацией.
Очевидно, что на формах нарушились привязки и прочее, т.е. диалог формы не был полностью взят из конфигурации поставщика. В данном случае в диалоге формы остались наши объекты, с одной стороны это хорошо, с другой стороны, местоположение наших элементов на форме не всегда оптимально, особенно в связи с добавлением новых элементов поставщика, наблюдается изменение позиций обхода и нарушение привязок. В некоторых случаях легче вручную добавить наши элементы в диалог формы, чем делать исправления.
2. Флаг обновления формы выставлен, обновление сделано в режиме «Взять из новой конфигурации поставщика»
В данном случае диалог формы элемента полностью приводится в соответствие с диалогом формы элемента поставщика.
Вернемся к обновлению. С модулями объекта и модулями менеджера документов поступаем также как с общими модулями, обновляем их по процедурно. С формами документов поступаем аналогично тому, как поступали с формами справочников.
Отдельно нужно выделить работу с ролями. Не смотря на то, что в примере не требуется обновлять роли поговорить об этом стоит. Рассмотрим самый простой случай, когда в конфигурации поставщика содержится новый объект. В этом случае потребуется обновление роли « Полные права », но данная роль может содержать какие-то созданные нами объекты, например, справочники, документы и прочее.
Кажется, что с ролью «Полные права» все просто, объединяем их полностью, права на нетиповые объекты сохранятся в них все равно. Так и есть, права на нетиповые объекты никогда не пропадут, но у всех этих объектов будет включен флаг «Интерактивное удаление», что не всегда хорошо. При сравнении конфигураций старого релиза и подготовленной нового релиза это хорошо видно:
С остальными ролями поступаем аналогично тому, как мы работаем с модулями - если наших изменений больше, то не объединяем роль, после обновления добавляем в нее то, что добавил поставщик в новом релизе.
После того как проработали все дважды измененные объекты в окне обновления нажимаем «Выполнить»
На вопрос о том, что измененные нами объекты будут загружены из новой конфигурации, отвечаем утвердительно.
В открывшемся окне «Настройка правил поддержки» проверяем, установленные флаги, хотя по умолчанию должны стоять правильно, нажимаем «ОК».
По окончании процесса объединения сохраняем основную конфигурацию, конфигурацию базы данных пока не обновляем.
Теперь в конфигурацию for_updating добавляем те минимальные доработки, которые не удалось правильно обновить штатными средствами.
Чтобы удобнее было проконтролировать выполнение данного процесса, в базе base запустим сравнение конфигурации поставщика и основной конфигурации старого релиза.
В базе for_updating сделаем тоже самое. Контролируем дважды измененные объекты, различий быть не должно.
После того как обновление в базе for_undating будет завершено обновляем конфигурацию базы данных и тестируем некоторые моменты, что именно хорошо бы протестировать станет понятно в процессе обновления, тут все индивидуально.
Обновление в рабочей базе желательно выполнять с помощью поддержки «Конфигурация» – «Поддержка» – «Обновить конфигурацию». При этом дважды измененные объекты будут загружены из нового релиза, т.е. наши изменения затрутся (конфигурацию не сохраняем!), но потом при объединении с подготовленной конфигурацией мы их восстанавливаем. После этого можно сохранить конфигурацию, обновить конфигурацию базы данных.
Иногда случается так, что обновление 1с устанавливается не должным образом, а например вместо обновления программист выполняет "Сравнение, объединение конфигурации 1с". При выполнении этих действий сама конфигурация обновляется, а вот версия конфигурации поставщика не обновляется и остается старой.
Конфигурация поставщика может быть обновлена только в нетиповой базе, для того чтобы посмотреть текущую версию поставщика в конфигураторе выполним следующие действия, нажмем "Конфигурация" ---> "Поддержка" ---> "Настройка поддержки". Для того чтобы посмотреть название и версию конфигурации зайдем "Справка" ---> "О программе".
В окне ниже мы видим где пишется версия конфигурации поставщика и версия самой конфигурации 1с.
Для того чтобы обновить конфигурацию поставщика выполним следующие действия, в конфигураторе выбираем вкладку "Конфигурация" ---> "Поддержка" ---> "Обновить конфигурацию"
Теперь в появившемся окне выбираем второй вариант предложенный системой, это "Выбор файла обновления", нажимаем "Далее".
В новом окне нужно нажать на три точки и выбрать файл с обновлением, версия которого в точности соответствует версии вашей конфигурации. Файл должен быть с расширением (*.cf), то есть быть полной конфигурацией, если у вас файл (*.cfu) то ничего не получится, так как это файл обновления конфигурации, а не файл самой конфигурации.
Теперь наблюдаем окно примерно следующего вида, нажимаем "Продолжить обновление".
На этой странице ничего не меняем, просто жмем ОК.
После данных действий система 1с начнет обновление конфигурации поставщика, через некоторое время вы будете наблюдать окно с двумя деревьями объектов (сравнение и объединение конфигураций), нужно везде снять галочки, после жмем "Выполнить".
Теперь когда прошло объединение конфигураций мы увидим окно которое представлено ниже, нажимаем "ОК".
Введение в поставку и поддержку конфигураций
Рассмотрим типичную ситуацию. Фирма-поставщик выпускает тиражную конфигурацию. Клиент приобретает ее и адаптирует под свои требования. Через некоторое время поставщик выпускает новую версию, и перед клиентом встает вопрос обновления, то есть интеграции своих изменений с изменениями поставщика. Ручное объединение в подобных случаях очень трудоемко. Требуется составить список всех отличий своей конфигурации от старой конфигурации поставщика и заново внести их в новую версию. Можно делать и наоборот, то есть подготовить список изменений поставщика и внести их в свою конфигурацию, но это ничего не меняет. Многое также зависит от механизма сравнения конфигураций и подготовки отчета различий. В платформе "1С:Предприятие" версии 8 этот механизм был существенно улучшен по сравнению с "1С:Предприятием" версии 7.7, но даже самый лучший и подробный отчет от дальнейшей утомительной ручной работы не освобождает. Механизм поставки и поддержки конфигураций в значительной степени автоматизирует этот процесс.
Общая схема обновления
Подробно рассмотрим ситуацию на примере любого свойства объекта метаданных. Возможны следующие варианты:
Пользователь | Поставщик | Правило обновления | |
1 | Менял | Не менял | Взять из конфигурации пользователя |
2 | Менял | Менял | ? |
3 | Не менял | Не менял | Взять из конфигурации пользователя |
4 | Не менял | Менял | Взять из конфигурации поставщика |
Таблица 1. Правила обновления по умолчанию
Нетрудно заметить, что варианты 1, 3, 4 в большинстве случаев не требуют модифицировать предложенное правило. Самый сложный случай – второй. Здесь нельзя сделать никаких предположений, но можно по крайней мере автоматически определить все такие свойства и предоставить пользователю отфильтрованный список для указания правила в каждом конкретном случае.
Реализация в платформе "1С:Предприятие 8"
Общие понятия
В "1С:Предприятии 8" любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика. В качестве конфигурации поставщика может выступать конфигурация, созданная командой Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации . В результате выполнения этой команды создается файл конфигурации ( cf) . Файл, подготовленный командой Конфигурация - Сохранить конфигурацию в файл , в качестве конфигурации поставщика использовать нельзя. Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (1cd) или файла выгрузки информационной базы (dt), требуется подготовленный вышеописанным способом файл cf загрузить в требуемую информационную базу (возможно, в пустую), выполнив команду Конфигурация - Загрузить конфигурацию из файла . Затем, при необходимости, можно штатными средствами создать файл dt.
Существуют два способа встать на поддержку конфигурации поставщика. Первый - использовать конфигурацию, подготовленную вышеописанным способом (при необходимости внося в нее изменения). Фактически подготовленная конфигурация поставщика находится на поддержке той конфигурации, в которой она была создана. Аналогичный результат достигается через команды Конфигурация - Загрузить конфигурацию из файла и Администрирование - Загрузить информационную базу . Второй способ позволяет поставить на поддержку уже созданную конфигурацию пользователя. Для этого необходимо выполнить команду Конфигурация - Сравнить, объединить с конфигурацией из файла . Если в качестве выбранного файла указывается файл конфигурации поставщика, и конфигурация пользователя уже не находится на ее поддержке, предлагается после объединения встать на поддержку.
Существуют два режима поддержки. Первый - в конфигурацию поставщика не вносятся изменения, она используется как есть. Такой режим возможен только при первом способе постановки на поддержку, и именно в нем конфигурация поставщика находится после ее создания. Все объекты конфигурации в этом случае заблокированы для изменений (в том числе и для добавления новых объектов). Второй режим - конфигурация находится на поддержке с возможностью изменений. Для того чтобы перейти в этот режим, необходимо открыть диалог настройки поддержки командой Конфигурация - Поддержка - Настройка поддержки и нажать кнопку Включить возможность изменения .
Способы обновления конфигурации. Обновление конфигурации может выполняться как с помощью файлов конфигурации поставщика новой версии, так и с помощью специальных файлов обновления конфигурации ( cfu) . Обновление конфигурации с помощью файлов (cf) может выполняться с любой версии (в том числе и более новой, при необходимости отказаться от внесенных изменений). При создании файла обновления поставщик указывает, для каких версий конфигурации он предназначен. Таких версий может быть несколько, но обновление может быть выполнено только с них. Это связано с тем, что файлы обновления включают в себя не всю конфигурацию, а только те изменения, которые существуют между конечной версией и указанными при создании файла обновлениями. Важно отметить, что файлы cfu не поддерживают обновления не только для более ранних версий конфигурации, чем они предназначены, но и для более поздних.
Приведем пример. Если конечная версия "4", а обновление создается только для версии "2", то невозможно будет выполнить обновление не только для версии "1", но и для версии "3". Такое ограничение связано с возможностью "обратных" изменений. То есть представим себе, что при переходе к версии "3" поставщик увеличил длину строки в типе реквизита, а в версии "4" изменил ее обратно. При подготовке обновления "2" - "4" это свойство в файл не попадет (поскольку в этих версиях значения совпадают). Если позволить использовать такой файл для обновления версии "3", то у пользователя окажется неправильная, увеличенная длина строки. Файлы обновления конфигурации имеют минимальный размер не только за счет включения в них только необходимых объектов, но и за счет применяемого в них сжатия данных. Они оптимальны для доставки обновления пользователю по низкоскоростным каналам связи. Обратной стороной является описанная выше меньшая гибкость их применения. С точки зрения дальнейшего процесса обновления применение файлов cf и cfu ничем не отличается.
Рисунок 1. Общая схема взаимодействия поставщика и пользователя
Выполнение обновления
Если конфигурация пользователя находится на поддержке без возможности внесения изменений, обновление представляет собой тривиальный, полностью автоматизированный процесс. Пользователь выполняет команду Конфигурация - Поддержка - Обновить конфигурацию , и после получения подтверждения выполняется обновление. Рассмотрим второй, наиболее интересный случай. Пользователь включил возможность изменения. Обновление конфигурации производится с использованием стандартного механизма сравнения и объединения, но пользователю предоставляется существенный дополнительный сервис. В процессе сравнения участвуют не две а три конфигурации - конфигурация пользователя, старая конфигурация поставщика (она хранится в конфигурации пользователя) и новая конфигурация поставщика, до которой и производится обновление. При этом система автоматически производит анализ сделанных изменений и, в соответствии с таблицей 1, расставляет правила объединения. Главную сложность представляет собой вариант 2, когда и пользователь, и поставщик меняли одно и то же свойство. Как отмечалось, разумных предположений автоматически сделать невозможно, но можно выделить эти случаи для пользователя. Все подобные свойства в дереве объединения показываются жирным шрифтом. Кроме того, в настройке фильтра просмотра можно указать флажок Показывать только дважды измененные свойства , и в дереве объединения будут показываться только те свойства, которые требуют ручной установки правил объединения. После выполнения объединения хранимая внутри пользовательской конфигурации конфигурация поставщика будет обновлена до новой версии.
Модификация алгоритма обновления с помощью правил поддержки
Пользователь может модифицировать приведенный алгоритм обновления с помощью правил поддержки, которые можно установить для каждого объекта метаданных. Необходимость в этом может возникнуть, если пользователь собирается самостоятельно выполнять дальнейшую модификацию объекта на себя и ему неинтересны изменения, вносимые поставщиком. Частный случай - пользователю вообще не требуется данный объект, и он хочет его удалить. Существуют три правила поддержки объекта метаданных:
- "Объект поставщика не редактируется" - пользователь не может изменять объект поставщика. Основное предназначение этого правила будет описано ниже, но пользователь может установить его с целью страховки от случайных изменений. При обновлении такие объекты будут полностью заменяться на объекты поставщика новой версии.
- "Объект поставщика редактируется с сохранением поддержки" - основное правило. В этом случае алгоритм объединения в точности совпадает с описанным.
- "Объект поставщика снят с поддержки" - пользователь не хочет выполнять дальнейшие обновления данного объекта. Для того чтобы удалить объект поставщика, предварительно ему необходимо установить данное правило.
Приведем расширенный вариант таблицы 1, с учетом правил поддержки.
Пользователь | Поставщик | Правила поддержки и обновления | |||||||
1 | Менял | Не менял |
| ||||||
2 | Менял | Менял |
| ||||||
3 | Не менял | Не менял |
| ||||||
4 | Не менял | Менял |
|
Таблица 2. Правила обновления по умолчанию с учетом правил поддержки
Ограничения действий пользователя со стороны поставщика с помощью правил поставки
Поставщик может ограничить возможные изменения пользователя с помощью правил поставки, которые можно устанавливать для каждого объекта метаданных. Данная возможность призвана ограничить возможные изменения конфигурации поставщика, нарушающие логику ее работы, после которых дальнейшая поддержка конфигурации теряет смысл. Существуют три правила поставки:
- "Изменения разрешены";
- "Изменения не рекомендуются";
- "Изменения запрещены".
Далее приводятся правила поддержки (по умолчанию и доступные для выбора пользователем), соответствующие различным правилам поставки.
Здравствуйте,
досталась Бух 3.0, в Cправка - О Программе пишет номер релиза 10.3.32.1
в Конфигурация - Настройка поддержки пишет номер релиза 10.3.19.4
Юзер утверждает что конфа регулярно обновлялась франчами.
Как такое возможно и что с этом делать - уж очень не хочется накатывать по-очереди с десяток обновлений. Целиком свежую конфу взять негде :(. Есть диск свежий ИТС но там я так понял - только обновления.
Буду признателен за подробный разжеванный ответ
С Уважением Kalina
(7) Тогда, что сейчас не делай, а результат все равно от тебя не зависит получается. Ибо будущее предопределено!
(4) Извини друг, конечно не Бух а УТ (просто с Бух такая же хрень), я так понимаю, что они как установились из коробки, так и не обновляли КП
(0) Франчи - такие франчи. Выкати им претензию.
А по сабжу:
1. Снимаешь конфу полностью с поддержки.
2. Делаешь "Сравнить, объединить. " с cf-ником из типовой того релиза, конфу поставщика ты хочешь добавить.
3. Всё галки снять. Жмакнуть oK
4. 1С-ка начнет вопить про то, что обновляется конфа и предложит поставить на поддержку. Далее, всё просто, ясно и понятно. Главное, вдумчиво читать и правильно поставить галочки))
(13) обновить конфой поставщика из типовой 10.3.32.1. Выгружаешь конфу поставщика оттуда - это будет файл cf, потом как обычно, Обновить и туда пишешь этот cf.
(16) ну НЕТУ у меня конфы поставщика из типовой, есть только обновления.
При их накатывании пишет что обновление не подходит для этого релиза КП .
Есть обновленная конфа ИБ, но как из нее сделать конфу для обновления, чтобы потом накатить на саму себя и заставить обновиться конфу поставщика. Вот в чем вопрос .
Спрошу еще разок, как обновить конфигурацию поставщика, имея обновленную основную конфигурацию, через много-много релизов?
Есть доступ к ИТС, но там только обновления.
Очень нехочется накатывать с десяток обновлений по-одному.
Если у тебя есть доступ только к обновлениям - то никак. Нужен как минимум сf-ник типовой конфы.
Если франчи обновляют конфигурацию, снятую с поддержки, то зачем вы туда лезете? Сломаете же.
(19) Выше я спрашивал, как такое возможно, это вообще - нормальное состояние базы . Т.е. франчи все правильно делают .
В конфе написано - Редактируется с Сохранением Поддержки.
(20) они неправильно делают. Нужно через обновление делать, а они через пункт сравнение-объединение конфигураций фигачат.
(20) а в чем проблема взять пустую базу УТ 10.3.19.4 и обновить 13 раз до 10.3.32? Это у вас займет один час, и будет полностью типовая 10.3.32. а вы тут уже неделю на форуме третесь.
Была похожая ерунда, основной конфиг и конфигурация БД обновились, а конфигурация поставщика осталась старой версии. В итоге следующее обновление начало ломать конфиг и дублировать уже добавленные ранее реквизиты. Помогло выгрузка в dt с последующей загрузкой. Конфиг поставщика пришел в соответствие с конфигом БД.
"Выше я спрашивал, как такое возможно" - такое возможно и твой пример свидетель этом. "как такое" - если редактировать конфигурацию, не используя обновление через поддержку.
"это вообще - нормальное состояние базы" - всё относительно. Слово "нормальное" тут не совсем в тему. База работает? Работает. Значит это "нормальное" состояние базы.
"Т.е. франчи все правильно делают" - ещё раз: всё относительно. Если рассматривать ситуацию в контексте дальнейшего обновления через поддержку - то нет, не правильно.
"редактируется с сохранением поддержки" - именно это правило конфигурации позволяет понятия "редактирование", "обновление" и "поддержка" рассматривать независимо/автономно/ друг от друга.
Редактирование - есть по факту. Обновление, если судить по конечному результату, тоже как бы присутствует.
Здравый смысл в действия франчей отсутствует. Но это только эмоции.
(28) внимательно прочитайте 2 и 3 строки поста (0) Налицо расхождение версий конфигов БД и поставщика. Я просто предложил один из вариантов как рашить проблему. "Не в тему" это в смысле не поболтать сначала на извечную тему "кто виноват" на десяток страниц?
Я так понял, что придется убить этот час (22) и обновляться несколько раз.
Честно говоря, думал можно как-то выгрузить основную, чтобы потом накатить ее как обновление и ею обновить КП, но видимо не судьба.
Всем спасибо .
(30) Ваш случай, описанный в (24), не аналогичен проблеме ТС. "Федот, да не тот"(с) Даже рядом не валялся (сори за мой плохой французский язык).
(32) Как раз таки аналогичен. Была конфа, у которой показывались разные версии в "о программе" и версия в поддержке. Ах, точно! Циферки были другие. Действиетльно, Федот, да не тот.
Вангую, что для конфы включена возможность изменений и франч делал какие-то существенные доработки по настоянию клиента. В итоге франчи идиоты, форуму спасибо, доработкам (а возможно что и данным) - "до свиданья".
(24)Бред какой то. Я регулярно забываю обновить конфигурацию поставщика(когда вспоминаю обновляю) ничего не сломалось до сих да и сломаться не может в принципе.
Обновляется конфигурация поставщика просто: выбираешь обновить, только не искать обновление а указываешь конкретный cf, в окне выбора объектов снимаешь все галки, нажимаешь ок. Готово. Если есть база с нужной конфигурацией поставщика, возьми оттуда. Где взять нужный фулл релиз бухгалтерии могу подсказать если сам не знаешь. Но такие подсказки здесь запрещены. Поэтому в почту.
(36) В чем же бред? Очередное обновление добавило реквизиты, но т.к. конфа поставщика не обновилась, то при последующем обновлении конфигуратор пытается добавить их снова, ибо идет сравнение с конфигурацией поставщика. Конфа, естественно, но поддержке с возможностью изменений.
И нету у меня cf, только cfu
А так да, можно и так обновить конфиг поставщика.
(33) Ценю Ваш юмор :) Но вы тормозите. У Вас случай - сбой(!) во время обновления и ваши действия по ликвидации его. А у ТС - нормальная база. Никаких выгрузок/загрузок *.dt не требуется.
(36)При обновлении загружается новая конфигурация поставщика и потом она сравнивается с конфигурацией БД, если реквизит есть, он изменяться не будет, если нет, удален не будет(если у объекта режим поддержки разрешены изменения)
(35) Не, не франч. Но что-то мне подсказывает, что учитывая скиллы ТС - это наиболее вероятный сценарий.
(41)Тебе надо сделать 2 простых шага:
1. Взять установочный cf нужного релиза
2. Заменить конфигурацию поставщика конфигурацией из данного cf.
Где проблема?
(уже уходя с ветки)
Для ТС всё можно сделать гораздо проще: требуем у франча "нормальный" CF актуальной версии (или иным способом получаем его) - "Загрузить конфигурацию из файла" (без изменения конфигурации БД!) и через "Конфигурация" - "Конфигурация базы данных" - "Сравнить, объединить с конфигурацией БД" - восстанавливаем свои изменения.
При установке обновлений на базу с конфигурацией, снятой с поддержки и доработанной, выполняется фактически обновление двух конфигураций: обновление конфигурации поставщика (обновление типовой конфигурации, без изменений, до текущего релиза), и обновление основной конфигурации.
Для обновления конфигурации поставщика используется файл cf типовой конфигурации, не снятой с поддержки. Для обновления основной конфигурации используется предварительно подготовленный файл cf (берется типовая конфигурация, в нее вносятся сделанные изменения, и конфигурация выгружается в файл cf)
Собственно процесс обновления выполняется в 2 этапа: обновление конфигурации поставщика, и обновление основной конфигурации. Последовательность выполнения этапов не принципиальна.
Для чего нужны 2 конфигурации в 1 флаконе? Такое сочетание конфигураций базы удобно использовать для получения перечня изменений в типовой конфигурации. В основной конфигурации содержится конфигурация с изменениями, в конфигурации поставщика – типовая. При помощи встроенного в платформу механизма сравнения конфигураций (в данном случае основной и поставщика), можно получить наглядное представление о том что было изменено в конфигурации в сравнении с типовой. Единственное условие для комфортной работы при сравнении – это поддержание одинаковых версий релизов обеих конфигураций. Для этого нужны 2 файла cf – один для основной, другой – для конфигурации поставщика.
Представим себе, что оба файла cf у нас есть (по подготовке cf с изменениями — отдельно) Назовем их, например, «Типовая_2_0_49_8.cf» и «Обновление_2_0_49_8.cf» Соответственно, первый файл – это обновление для конфигурации поставщика, второй – для основной конфигурации.
Начнем с обновления конфигурации поставщика.
В режиме Конфигуратор, идем в меню Конфигурация – Поддержка – Обновить конфигурацию. В получившемся диалоге выбираем переключатель «Выбор файла обновления», и говорим «Далее»
Далее нам предлагается указать файл обновления:
Тут все знакомо. Указываем файл «Типовая_2_0_49_8.cf», и нажимаем Готово
Со всем, что будет появляться дальше – соглашаться)))
После утрясения всех вопросов, платформа начнет загрузку конфигурации для сравнения. Это занимает некоторое время…
По окончании загрузки получаем следующее окно:
Здесь нам показывают различия между тем что у нас уже есть, и тем, что мы пытаемся загрузить. В первой колонке – различия между новой конфигурацией и конфигурацией базы данных (основной), во второй – различия между текущей конфигурацией поставщика, и загружаемой конфигурацией.
Так как нам нужно обновлять только конфигурацию поставщика, а основную пока не трогать, снимаем все галки в левой колонке (если снять самую верхнюю, все остальные ниже снимутся самостоятельно)
Нажимаем «Выполнить», ждем некоторое время…
В процессе загрузки может появиться следующее окно:
Это относится к блокировке объектов базы. Если все переключатели будут установлены в режим «Объект не редактируется», внесение изменений в конфигурацию будет невозможно без предварительного снятия конфигурации с поддержки (объекты на поддержке, снятые с поддержки и редактируемые с сохранением поддержки – отдельная тема) В большинстве случаев настройка правил поддержки выполняется так, как указано на снимке
Идем в меню Файл – Сохранить (платформа сохранит сделанные изменения), и затем в меню Конфигурация – Обновить конфигурацию базы данных. Процесс займет некоторое время, и будет требовать принятия изменений в течение реорганизации.
На этом первый этап закончен.
Обновление основной конфигурации.
В режиме Конфигуратор идем в меню Конфигурация – Сравнить, объединить с конфигурацией из файла. Сразу же получаем окно для выбора файла, в котором указываем наш файл для обновления основной конфигурации «Обновление_2_0_49_8.cf» Платформа сразу же начинает сравнение конфигураций.
Так как наш файл «Обновление_2_0_49_8.cf» содержит уже обновленную конфигурацию, с учетом всех изменений, то все галки в левой колонке теперь оставляем на месте.
После нажатия кнопки «Выполнить», будет выполнено объединение конфигураций (аналогично первому этапу)
Идем в меню Файл – Сохранить, затем Конфигурация – Обновить конфигурацию базы данных
После выполнения всех действий по обновлению, открываем базу в режиме Предприятия, и подтверждаем легальность получения обновлений
На самом деле, если изменения в конфигурации минимальны, и заранее известны, можно обойтись только одним этапом – обновлением конфигурации поставщика. При этом в левой колонке нужно снять галки с тех объектов, которые были изменены по отношению к типовой. Однако эта методика применима только в том случае, когда не требуется внесения изменений в формы и/или сравнения больших блоков кода. Новая типовая конфигурация будет наложена на текущую, за исключением тех объектов, которые мы снимем с объединения.
Методика обновления – универсальна, подходит не только для конфигураций «БухгалтерияПредприятия», но и для Комплексной, и для ЗУП, и для прочих…
Читайте также: