Хитрости платформы: использование конфигурации поставщика. Хитрости платформы: использование конфигурации поставщика Выполнение обновления с помощью конфигурации поставщика
Рассмотрим типичную ситуацию, в которой часто оказываются новички. Допустим имеется типовая конфигурация 1С:Комплексная автоматизация 8. Первоначально конфигурация была установлена из дистрибутива (допустим релиза 1.1.20.1). Затем в связи с необходимостью адаптации под специфику предприятия была включена возможность изменения (новички очень часто ошибочно называют это действие снятием с поддержки, хотя на самом деле это не так).
И вот спустя некоторое время мы имеем сильно доработанную, но все же типовую (в целях регламентированного учета мы регулярно выполняли обновление) конфигурацию. А дальше рассмотрим несколько гипотетических ситуаций:
1) Спустя какое-то время после очередного обновления мы получаем сообщение от бухгалтерии об ошибке, которая вылазит в момент проведения регламентной операции закрытия месяца. До этого такой ошибки не было, следовательно всему виной обновление. Вполне типовая ситуация. Мы начинаем диагностировать ошибку и видим, что ноги растут из общего модуля УчетНДСФормированиеДвижений. Начинаем разбираться и понимаем, что данный модуль был значительно переработан в типовой и после объединения мы «потеряли» часть процедур/функций (или как часто происходит в типовых, они «перепрыгнули» в другой общий модуль) . В виду хитросплетения общих модулей между собой в типовых, на этапе обновления не всегда можно выявить проблему, которая проявляет себя только при работе пользователей.
Итак мы понимаем, чтобы разобраться нам нужна типовая конфигурация текущего релиза (допустим 1.1.23.1). Но где ее взять? Если есть знакомый франч и он может оперативно переслать дистрибутив — прекрасно, но предположим его нет, а исправить проблему нужно срочно. (Варез не предлагать!). Более того, может и интернета не быть, и что делать в такой ситуации? Неоднократно был свидетелем процесса, когда человек для решения данной проблемы устанавливал новую базу из имеющегося первоначального дистрибутива, а затем последовательно ее обновлял до последнего, чтобы в чистой базе посмотреть «как оно должно быть на самом деле». А ларчик как всегда просто открывался:)
Теперь рассмотрим различные варианты решения:
а) Первый вариант: Меню -> Конфигурация -> Сравнение конфигураций, затем выбираем конфигурацию поставщика и сравниваем ее с основной конфигурацией.
Удивительно, но есть такие, кто про это не знает. Или при любых обстоятельствах используют пункт Сравнить, объединить с конфигурацией из файла (предварительно раздобыв/получив типовой.cf).
б) Второй способ подходит если нам нужно не только увидеть изменения, но и сразу выполнить объединение.
Меню -> Конфигурация -> Поддержка -> Настройка поддержки и внизу нажимаем кнопку Сравнить, объединить.
2) Другая ситуация: допустим мы изменили или удалили какой-то кусок типового кода, а через некоторое время оказалось, что мы допустили ошибку и нужно все вернуть обратно. И как часто происходит, бэкапа сохраненной конфигурации до внесенных изменений не оказывается. Но мы то точно знаем, что этот кусок кода содержится в типовой, поэтому конфигурация поставщика решила бы проблему.
Естественно можно поступить как и в первом случае. Дождаться окончания процесса сравнения, и из окна сравнения конфигураций открыть типовой модуль и скопировать оттуда код.
Некоторые делают именно так, но если мы имеем дело с монстром типа УПП, к тому же сильно измененной, то окончания процесса сравнения можно ждать ооочень долго. Имей мы файл.cf его можно было бы просто открыть в окне конфигурации (кстати про эту возможность знают тоже не все новички) и скопировать оттуда нужный код.
И возникает резонный вопрос, как же все таки сохранить конфигурацию поставщика в файл? Почему нет пункта меню аналогично Сохранить конфигурацию в файл для основной конфигурации или Сохранить конфигурацию БД в файл, для конфигурации базы данных. А где такой же для конфигурации поставщика? На самом деле он тоже есть, только зарыт чуть глубже. А именно все в той же форме настройки поддержки.
Просто многие единственный раз открывают данную форму только лишь для включения возможности изменения и больше никогда к ней не возвращаются.
А в нашем случае можно было поступить еще проще, даже не сохраняя конфигурацию в файл, нажать кнопку Открыть. Эффект тот же, но гораздо быстрее.
А для чего еще может понадобиться сохранение конфигурации поставщика в файл?
3) Рассмотрим следующую ситуацию. Допустим на начальном этапе существования конфигурации в типовой не было нужного нам функционала и было принято решение о доработке. Доработка была минимальной, но в дальнейшем это все же создавало неудобства при обновлении. Но затем, спустя какое-то время, мы обнаруживаем, что данный функционал (как в свое время было с версионированием объектов) появился в типовой (и как часто бывает, реализован на порядок лучше, чем «кустарная» доработка).
Приведу еще несколько примеров реальных ситуаций, когда может потребоваться откат к типовой конфигурации:
1. Пару раз сталкивался с конфигурациями, в которых доработке подвергались только макеты печатных форм. Ввиду отсутствия опыта либо по незнанию, программист сопровождавший конфигурацию, вместо создания внешней печатной формы снимал конфигурацию с поддержки и дорабатывал встроенные макеты (зачастую банально чтобы добавить логотип компании), после чего пользователи лишались возможности автоматического режима обновления.
2. Опять же по незнанию типового функционала (очень часто этим страдают бывшие "семерочники") вместо использования свойств и категорий были добавлены реквизиты справочников/документов, когда это не имело веских на то оснований (данные например использовались только для вывода в печатные формы).
Конечно же это не проблема, имей мы дело с УТ или другой конфигурацией управленческого плана, где в общем не критичны обновления, но в данном примере речь шла про доработанные УПП либо комплексную автоматизацию. И получается из-за незначительных доработок, которые можно было реализовать без снятия с полной поддержки, мы имеем никому не нужный геморрой с типовыми обновлениями.
Возникает резонное желание отказаться от внесенных доработок и снова поставить конфигурацию на полную поддержку. Как это сделать?
Единственный способ поставить конфигурацию снова на полную поддержку - это загрузить (не в режиме сравнения и объединения, а именно пункт Загрузить конфигурацию из файла) типовой.cf. Вот для этого нам как раз и пригодится возможность сохранения конфигурации поставщика в файл.cf. Делаем сохранение, затем загрузку, и после обновления конфигурации базы данных, получаем типовую конфигурацию в первозданном виде, т.е. с замочком:) Естественно перед выполнением данных действий вы должны заранее позаботиться о сохранении/переносе необходимых данных, которые "смоет" после возврата к типовой конфигурации и обязательно сделать резервную копию базы данных!
Вот такие как оказалось нехитрые возможности имеются в арсенале разработчика, но незнание этих приемов на практике может вылиться во многочасовую ненужную возню, описанную выше. Так что кто знал — молодец, а кто не знал — берите на вооружение и экономьте свое время.
В данной статье я хочу показать сервисные возможности платформы 1С:Предприятие 8, в части использования конфигурации поставщика, которые очень часто бывают востребованы, но как показала практика, знакомы отнюдь не всем начинающим и даже опытным специалистам.
Рассмотрим типичную ситуацию, в которой часто оказываются новички. Допустим имеется типовая конфигурация 1С:Комплексная автоматизация 8. Первоначально конфигурация была установлена из дистрибутива (допустим релиза 1.1.20.1). Затем в связи с необходимостью адаптации под специфику предприятия была включена возможность изменения (новички очень часто ошибочно называют это действие снятием с поддержки, хотя на самом деле это не так).
И вот спустя некоторое время мы имеем сильно доработанную, но все же типовую (в целях регламентированного учета мы регулярно выполняли обновление) конфигурацию. А дальше рассмотрим несколько гипотетических ситуаций:
1) Спустя какое-то время после очередного обновления мы получаем сообщение от бухгалтерии об ошибке, которая вылазит в момент проведения регламентной операции закрытия месяца. До этого такой ошибки не было, следовательно всему виной обновление. Вполне типовая ситуация. Мы начинаем диагностировать ошибку и видим, что ноги растут из общего модуля УчетНДСФормированиеДвижений. Начинаем разбираться и понимаем, что данный модуль был значительно переработан в типовой и после объединения мы «потеряли» часть процедур/функций (или как часто происходит в типовых, они «перепрыгнули» в другой общий модуль) . В виду хитросплетения общих модулей между собой в типовых, на этапе обновления не всегда можно выявить проблему, которая проявляет себя только при работе пользователей.
Итак мы понимаем, чтобы разобраться нам нужна типовая конфигурация текущего релиза (допустим 1.1.23.1). Но где ее взять? Если есть знакомый франч и он может оперативно переслать дистрибутив - прекрасно, но предположим его нет, а исправить проблему нужно срочно. (Варез не предлагать!). Более того, может и интернета не быть, и что делать в такой ситуации? Неоднократно был свидетелем процесса, когда человек для решения данной проблемы устанавливал новую базу из имеющегося первоначального дистрибутива, а затем последовательно ее обновлял до последнего, чтобы в чистой базе посмотреть «как оно должно быть на самом деле». А ларчик как всегда просто открывался (IMG:)
Теперь рассмотрим различные варианты решения:
а) Первый вариант: Меню -> Конфигурация -> Сравнение конфигураций, затем выбираем конфигурацию поставщика и сравниваем ее с основной конфигурацией.
Удивительно, но есть такие, кто про это не знает. Или при любых обстоятельствах используют пункт Сравнить, объединить с конфигурацией из файла (предварительно раздобыв/получив типовой.cf).
б) Второй способ подходит если нам нужно не только увидеть изменения, но и сразу выполнить объединение.
Меню -> Конфигурация -> Поддержка -> Настройка поддержки и внизу нажимаем кнопку Сравнить, объединить.
2) Другая ситуация: допустим мы изменили или удалили какой-то кусок типового кода, а через некоторое время оказалось, что мы допустили ошибку и нужно все вернуть обратно. И как часто происходит, бэкапа сохраненной конфигурации до внесенных изменений не оказывается. Но мы то точно знаем, что этот кусок кода содержится в типовой, поэтому конфигурация поставщика решила бы проблему.
Естественно можно поступить как и в первом случае. Дождаться окончания процесса сравнения, и из окна сравнения конфигураций открыть типовой модуль и скопировать оттуда код.
Некоторые делают именно так, но если мы имеем дело с монстром типа УПП, к тому же сильно измененной, то окончания процесса сравнения можно ждать ооочень долго. Имей мы файл.cf его можно было бы просто открыть в окне конфигурации (кстати про эту возможность знают тоже не все новички) и скопировать оттуда нужный код.
И возникает резонный вопрос, как же все таки сохранить конфигурацию поставщика в файл? Почему нет пункта меню аналогично Сохранить конфигурацию в файл для основной конфигурации или Сохранить конфигурацию БД в файл, для конфигурации базы данных. А где такой же для конфигурации поставщика? На самом деле он тоже есть, только зарыт чуть глубже. А именно все в той же форме настройки поддержки.
Просто многие единственный раз открывают данную форму только лишь для включения возможности изменения и больше никогда к ней не возвращаются.
А в нашем случае можно было поступить еще проще, даже не сохраняя конфигурацию в файл, нажать кнопку Открыть. Эффект тот же, но гораздо быстрее.
А для чего еще может понадобиться сохранение конфигурации поставщика в файл?
3) Рассмотрим следующую ситуацию. Допустим на начальном этапе существования конфигурации в типовой не было нужного нам функционала и было принято решение о доработке. Доработка была минимальной, но в дальнейшем это все же создавало неудобства при обновлении. Но затем, спустя какое-то время, мы обнаруживаем, что данный функционал (как в свое время было с версионированием объектов) появился в типовой (и как часто бывает, реализован на порядок лучше, чем «кустарная» доработка).
Приведу еще несколько примеров реальных ситуаций, когда может потребоваться откат к типовой конфигурации:
1. Пару раз сталкивался с конфигурациями, в которых доработке подвергались только макеты печатных форм. Ввиду отсутствия опыта либо по незнанию, программист сопровождавший конфигурацию, вместо создания внешней печатной формы снимал конфигурацию с поддержки и дорабатывал встроенные макеты (зачастую банально чтобы добавить логотип компании), после чего пользователи лишались возможности автоматического режима обновления.
2. Опять же по незнанию типового функционала (очень часто этим страдают бывшие «семерочники») вместо использования свойств и категорий были добавлены реквизиты справочников/документов, когда это не имело веских на то оснований (данные например использовались только для вывода в печатные формы).
Конечно же это не проблема, имей мы дело с УТ или другой конфигурацией управленческого плана, где в общем не критичны обновления, но в данном примере речь шла про доработанные УПП либо комплексную автоматизацию. И получается из-за незначительных доработок, которые можно было реализовать без снятия с полной поддержки, мы имеем никому не нужный геморрой с типовыми обновлениями.
Возникает резонное желание отказаться от внесенных доработок и снова поставить конфигурацию на полную поддержку. Как это сделать?
Единственный способ поставить конфигурацию снова на полную поддержку - это загрузить (не в режиме сравнения и объединения, а именно пункт Загрузить конфигурацию из файла) типовой.cf. Вот для этого нам как раз и пригодится возможность сохранения конфигурации поставщика в файл.cf. Делаем сохранение, затем загрузку, и после обновления конфигурации базы данных, получаем типовую конфигурацию в первозданном виде, т.е. с замочком (IMG:) Естественно перед выполнением данных действий вы должны заранее позаботиться о сохранении/переносе необходимых данных, которые «смоет» после возврата к типовой конфигурации и обязательно сделать резервную копию базы данных!
Вот такие как оказалось нехитрые возможности имеются в арсенале разработчика, но незнание этих приемов на практике может вылиться во многочасовую ненужную возню, описанную выше. Так что кто знал - молодец, а кто не знал - берите на вооружение и экономьте свое время.
[необходимо зарегистрироваться для просмотра ссылки]
В моем случае «Управление торговлей», редакция 10.3 дополнена отраслевым решением «БИТ: Управление автосервисом 8». Компании, использующие отраслевые решения, как правило, дорабатывают конфигурацию под свои нужды и не обновляют их на новые релизы от поставщика. Следовательно, осталась «Управление торговлей», релиз 10.3.13.2. Плюс конфигурация поставщика хоть и называется «Управление торговлей», тем не менее, объекты, относящиеся к конфигурации «БИТ: Управление автосервисом 8», так же находятся на поддержке (рис. 1). Это случай, когда релизы конфигурации поставщика и конфигурация базы данных (далее БД) формально совпадают, а фактически конфигурация поставщика - не «Управление торговлей», редакция 10.3.
Следовательно, при обновлении на следующий релиз «Управление торговлей» механизм обновления предложит удалить все объекты, которые относились с отраслевому решению (рис. 2).
Таким образом, возникает задача востановления поставщика конфигурации. Также данная задача может возникнуть, если обновление БД проводилось через «Сравнение, объединение» с новым файлом конфигурации.
Задача решается в два этапа. Для этого понадобится cf-файл конфигурации, который соответствует релизу БД. Релиз БД можно посмотреть в «Справка» − «О программе» (рис. 3).
Внимание! Перед проделыванием следующих операций сделайте резевную копию БД.
1) Нажимаем «Конфигурация» − «Поддержка» − «Настройки Поддержки». Появится окно «Настройки поддержки», нажимаем «Снять с поддержки» (рис. 4). В диалоговом окне с сообщением о том, что снятие с поддержки приведет к невозможности получать обновление от поставщика, отвечаем «Да».
Обратите внимание, что пиктограмма с изображением желтого кубика в дереве конфигурации больше не отображается.
2) Нажимаем «Конфигурация» − «Сравнить, объединить с конфигурацией из файла». Появится окно с предложением поставить конфигурацию на поддержку. Отвечаем «Да» (рис. 5).
Теперь, чтобы не потерять изменения типовых объектов в конфигурации, снимаем галочку с корневого узла и нажимаем «Выполнить». В настройках правил поддержки отвечаем «ОК» (рис. 6).
Теперь конфигурация поставщика соответствует конфигурации БД. Однако есть небольшое техническое замечание − объекты, у которых были изменения, не находятся на поддержке (рис. 7). При обновлении такие объекты меняться не будут. Так что, нужно поставить их на поддержку с возможностью редактирования.
3) Нажимаем «Конфигурация» − «Поддержка» − «Настройки поддержки». В появившемся окне нажимаем «Сравнить, объединить». В окне сравнения, объединения снимаем все галочки, выделяем объект, который ставим на поддержку, и нажимаем «Изменить». В появившиеся окне выбираем «Объект поставщика редактируется с сохранением поддержки», нажимаем «ОК» и «Выполнить» (рис. 8). Галочка «Устанавливать для подчиненных объектов» полезна в том случае, если проводимое изменение справедливо для всех подчиненных объектов. Платформа «1С:Предприятие 8» не позволит провести изменения, если, например, в подчиненных объектах добавлены реквизиты, и вы поставите их на поддержку.
Выделяем объект, который ставим на поддержку.
Теперь информационная база на поддержке нужной конфигурации.
Был вопрос:
Сколько конфигураций находится в информационной базе?
Правильный ответ 3
В структуру ИБ входят:
1. Основная конфигурация.
2. Конфигурация базы данных.
3. Конфигурация поставщика
(может и отсутствовать).
4. Плюс пользовательские данные (документы, справочники и т.п.)
Конфигурация определяет структуру базы данных и содержит алгоритмы, которые обеспечивают работу с данными.
С основной конфигурацией работают разработчики. С конфигурацией базы данных работают пользователи.
Конфигурация поставщика – исходная конфигурация поставщика типового решения.
Если информационная база установлена из шаблона и находится на поддержке поставщика, то внутри ИБ будет находиться конфигурация поставщика .
Если конфигурация находится на поддержке и изменения объектов запрещены , то в информационной базе хранится две конфигурации – основанная конфигурация и конфигурация базы данных.
При включении возможности изменения конфигурации (команда Включить возможность изменения в диалоге «Настройка поддержки «), платформа из основной конфигурации создает конфигурацию поставщика . Размер ИБ увеличивается.
Конфигурация поставщика доступна только для чтения.
Для просмотра конфигурации поставщика необходимо выбрать пункт
Конфигурация – Поддержка – Настройка поддержки – Открыть.
Информационная база может содержать несколько конфигураций поставщиков, в том случае если конфигурация стоит на поддержке нескольких поставщиков. Такая схема встречается при использовании отраслевых тиражных решений.
Основы поддержки 1С
Обновление 1С можно произвести в пользовательском режиме, в режиме конфигуратора и в настройки сравнения и объединения.
Снятие с поддержки
В диалоге «Настройка поддержки» при нажатии кнопки Снять с поддержки происходит удаление конфигурации поставщика . Такую возможность необходимо применять в тех случаях, когда типовое решение используется как основа для собственной разработки и не планируется его сопровождение.
Если нужно выгрузить конфигурацию поставщика. То это можно сделать из Поддержка – Настройка поддержки. В диалоге «Настройка поддержки» нажать кнопку Сохранить в файл.
