1с обновить типовую доработками
В этой инструкции нетипового обновления измененной 1с 8.3 я не буду описывать базовые вещи, такие как: как открыть конфигуратор, что такое конфигурация БД, конфигурация поставщика и основная конфигурация. Об это и там много написано, и вы можете самостоятельно найти эту информацию на просторах интернета. Я постараюсь описать основные моменты процесса обновления и на что нужно обратить внимание.
Я взял для примера нетиповую бухгалтерию 3.0.51.22 и покажу как обновить ее до версии 3.0.53.29. На платформе версии 8.3.10.2561 (нет большой разницы на более старых платформах, просто раньше окошко сравнения выглядело чуть иначе).
Скажу сразу, будет много картинок и мало текста. Я считаю, что визуально проще запоминать процесс, чем читать море текста.
1. Проверить соответствие конфигурации БД и конфигурации поставщика.
Для этого вам нужно
-
первое – открыть из меню «Справка» - «О программе»
и в разделе конфигурация найти версию, указанную в скобках.
Эта же информация будет совпадать с версией разработки в свойствах конфигурации.
И в появившемся окне посмотреть версию (версии может вообще не быть, если конфигурация поставщика была удалена).
При совпадении можете смело переходить к пункту 2.
1а. Постановка конфигурации на поддержку.
Если у вас отличаются версия БД и версия конфигурации поставщика, то вам нужно удалить текущую конфигурацию все через то же меню: конфигурация – поддержка – настройка поддержки. И нажать кнопку «Снять с поддержки».
Далее нужно сравнить-объединить с типовой конфигурацией версии, указанной в «Справка» - «О программе». И на вопрос «Поставить на поддержку?» нажать «Да».
После «недолгого» ожидания снимаем все галочки. Ну и можно убрать галку «Сохранять настройки автоматически». И жмем выполнить.
В результате мы получим конфигурацию на поддержке с одинаковыми версиями баз данных.
2. Обновление базы.
Теперь можно переходить к обновлению.
Скажу сразу обновление делать нужно ТОЛЬКО через меню «Конфигурация» - «Поддержка» - «Обновить конфигурацию…».
Использовать «Сравнить, объединить с конфигурацией из файла…» НЕЛЬЗЯ. При использовании этого механизма вам при следующем обновлении придется переходить к пункту 1а. Поэтому давайте не будем так делать и создавать себе (или тому, кто будет в следующий раз обновлять базу) лишние проблемы.
Ожидаем, пока пройдет сравнение объектов.
Далее нам нужно внизу из списка выбрать пункт «показывать только дважды измененные свойства.
Так же хочу сказать по старые версии, раньше это был флажок.
Итак, мы теперь видим гораздо меньше объектов.
Если у вас пусто, то вам несказанно повезло, и вы можете смело нажимать кнопку «выполнить» и считайте обновление закончено. Ну у нас не все так просто, поэтому пробегусь по основным объектам.
-
Подсистемы – ставим режим «Объединить»
Первое что хочется сказать. Ни в коем случае не переключайте режим объединения. Он должен стоять «Взять из новой конфигурации поставщика». Иначе вы получите в базе мусор с комментарием MGR.
Никаких кнопок «показать различия в модулях…»!
Жмем именно на значок шестеренки рядом с модулем
Открывается окошко, в котором очень много изменений в функциях и процедурах.
Для того чтобы понять в какой функции были изменения нам нужно будет либо взять копию базы, либо через меню конфигурация сохранить конфигурацию в файл. И дальше загрузить в пустую базу. Далее зайти в меню «конфигурация» и нажать «Сравнить конфигурации…»
Выбрать сравнение основной конфигурации с конфигурацией поставщика.
И вот ту можно уже посмотреть изменения через «показать различия в модулях…». Т.к. мы не собираемся ничего менять, мы только хотим посмотреть, что было изменено.
И мы видим, что в функцию «Просклонять» был добавлен кусок кода. Все изменения можно посмотреть, нажимая на синие стрелки.
Вернемся к обновляемой конфигурации. Там мы через значок шестеренки зашли с режим объединения модулей. Далее ставим все галки…вручную..говоря про себя «спасибо» разработчикам платформы :)
Находим нашу функцию просклонять. Находим измененный элемент. Надеюсь, теперь стало понятно, зачем нужно отделять любой добавленный свой код комментариями – правильно, чтобы не гадать при обновлении, откуда взят этот код.
Нажимаем значок лупы, и платформа выделит строчку кода, куда нужно этот текст добавить.
Копируем его из верхнего окна и вставляем в нижнее окно.
Так проделать со всеми модулями. Если модуль не был изменен, как в нашем случае со справочником валюты. Мы просто ставим режим «Взять из новой конфигурации поставщика» и НЕ нажимаем на шестеренку (рядом с шестеренкой не должно стоять зеленой галочки, это означает что код полностью будет взят из новой конфигурации, без ручной настройки).
Отлично. Теперь пробежавшись по всем объектам можно снять галку «сохранять настройку автоматически» и потом «выполнить»
В следующем окне оставляем галки, как показано на картинке. И никак иначе. Должны стоять обе галки – «объекты редактируются с сохранением поддержки». Нажимаем ОК.
Все. Обновление нетиповой конфигурации 1с завершено.
Этот метод не претендует на идеал, но я думаю, многие совершают ошибки в этих шагах.
Конечно, я рассказал не все, тут еще много подводных камней. Но я думаю 90% обновлений можно смело обновлять по этой инструкции.
Надеемся, данная информация была полезна. При необходимости мы можем выгодно лицензировать вашу 1С
Также у вас есть возможность заработать на партнерской программе , приводя клиентов и получая комиссию с их покупок.
В свое время не смог найти краткой инструкции по обновлению, поэтому пишу эту статью.
Помните анекдот про молодых охотников и медведя. Так вот – главное не бояться.
Статья предназначена для самых начинающих, коими все когда-то были.
Итак, у нас должна быть копия рабочей базы с идентичной конфигурацией, на которой мы и будем выполнять обновление с последующей загрузкой cf-файла в рабочую базу.
Выгружаем конфигурацию рабочей базы в cf-файл.
Сравниваем выгруженную рабочую конфигурацию с конфигурацией нашей копии – они должны быть идентичны. Если нет, то можем снять конфигурацию копии с поддержки и полностью загрузить конфигурацию из файла.
Подготавливаем файл обновления (скачиваем с сайта 1С и устанавливаем какую-нибудь свою папку).
В копии нажимаем: Конфигурация – Поддержка – Обновить конфигурацию.
Устанавливаем переключатель на «Выбор файла обновления» и указываем наш файл обновления. Нажимаем «Готово». Ждем, когда выполнится сравнение.
После того как появилось окно сравнения, первым делом снимаем галочку с корневого элемента конфигурации.
Потом заходим в настройки и ставим галочку разрешить удаление – это важно иначе можем получить ошибки после обновления
Потом заходим в фильтр и устанавливаем «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
При этом фильтре устанавливаем галку на корневом элементе конфигурации – у нас выберутся все необходимые объекты.
Заходим опять в фильтр, оставляем «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика», и устанавливаем галку «Показывать только дважды измененные свойства» - это те объекты поставщика, в которые вносили изменения мы и есть изменения в новой конфигурации поставщика – вот с ними нам и нужно разбираться.
Применяем фильтр – ну вот объектов значительно меньше и уже не так страшно (помним – главное не бояться).
У ролей и тех объектов, у которых изменен состав – устанавливаем «объединить с приоритетом новой конфигурации поставщика».
У модулей в колонке «Режим объединения и порядок подчинения» нажимаем «Открыть».
Анализируем процедуры и функции модуля и по каждой принимаем решение (см галочки и режим объединения). Зачастую бывает достаточно установки или снятия необходимых галочек - галочка снимается, если в процедуре только наши изменения (для этого и нужны комментарии) или оставляется, если в процедуре только изменения поставщика.
Если в новой конфигурации поставщика отсутствует типовая процедура (не наша) то нужно установить галочку (режим объединения – Удалить).
Если есть изменения и наши и поставщика – то нужно режим объединения установить «объединить». Записать в каком модуле, в какой процедуре, какие изменения и после объединения откорректировать соответствующий модуль. Т.е. например, ставим «объединить с приоритетом новой конфигурации», а потом снимаем комментарии с наших изменений (программа закомментирует наши изменения).
Самое неприятное – изменение форм. Для того чтобы понять что менялась сама форма а не просто модуль, делаем следующее: встаем на необходимый объект, нажимаем правую кнопку мыши и выбираем «Отчет о сравнении объектов».
Далее делаем настройку как показано на скриншоте. И анализируем изменения.
Возможно, достаточно будет объединить форму с приоритетом новой конфигурации поставщика или вовсе взять из файла, если модуль формы не менялся.
После всех корректировок нажимаем «Выполнить», игнорируем страшные предупреждения программы если они появляются и не соглашаемся на предложения включить дополнительные объекты в объединение (мы же до этого все делали правильно правда?) Делаем в итоговой конфигурации необходимые изменения. Сохраняем конфигурацию и обновляем конфигурацию базы данных. Запускаем 1С Предприятие и проводим обновление. Проверяем, что ключевые документы открываются и проводятся без ошибок. Сохраняем конфигурацию в файл.
Далее делаем копию рабочей базы. Копию нужно делать средствами SQL если база серверная или копированием соответствующей папки если файловая. Файл dt не подойдет. То, что вы выгрузите этот файл, еще не гарантия что вам удастся его загрузить, к тому же выгрузка/загрузка dt на больших базах занимает много времени.
Заходим в конфигуратор рабочей базы и через сравнение и объединение проверяем с файлом конфигурации, который мы выгружали из этой базы – конфигурации должны быть идентичны. Снимаем конфигурацию с поддержки (вы же помните – главное не бояться). Конфигурация – Поддержка – Настройка поддержки – Снять с поддержки. Сохраняем. Загружаем конфигурацию из файла (Конфигурация – Загрузить конфигурацию из файла – Выбираем наш файл конфигурации, который мы выгрузили из копии).
После загрузки сохраняем конфигурацию, обновляем информационную базу. Проводим обновление в режиме предприятия. Ждем отзывов от благодарных пользователей.
Так можно накатить сразу несколько релизов (на копии мы последовательно накатываем релизы с обновлением в режиме предприятия), а на рабочую базу накатываем общий получившийся в результате этого фай cf.
1. Лучшая доработка, это доработка без изменения конфигурации. Если возможно, используем справочник "Внешние отчеты и обработки"
2. Если без доработок никак, стараемся создавать новые объекты, в частности:
2.1. При добавлении новых объектов, реквизитов обязательно добавляем префикс
2.2. Создаем общие модуля (для сервера, клиента и пр.), куда стараемся переносить все изменения. Остальные модули вызывают данный код.
2.3. Используем подписки на события для проверки значений, корректировки проведения документов.
2.3. Для новых объектов лучше создать новую роль, а не редактировать старую
2.4. Все новые и измененные объекты включаем в специально созданную для этого подсистему
3. Если необходимо изменить код модуля:
3.1. Выделяем комментарием все сделанные изменения, причем комментарий должен позволять однозначно найти все изменения конфигурации (используя глобальный поиск) и при этом не дать лишних строк. Желательно добавлять метку задачи (код), в рамках которой были изменения, дату и автора решения.
3.2. Старый код не удаляем, а оставляем закомментированным
3.3. Комментарий добавляем перед и после изменений, с открывающим и закрывающим символом соответственно (например: + и -)
3.4. Самое главное, чего, собственно, нигде не встречал и что сильно упрощает жизнь, создаем процедуру "НеТиповыеИзменения". Данная процедура должна содержать в себе копию всех комментариев по сделанным изменениям с указанием процедур в которых были внесены данные изменения . Т.е. при сравнении/объединении модуля мы вначале определяем процедуры, содержащие изменения, и не проходим по всем процедурам модуля.
Как пример на примере пункта 3.5 в конце модуля добавляется процедура:
3.5. С пасибо unichkin. Все изменения по возможности выносить в отдельные процедуры, как один из минусов сложность в анализе изменений в одном месте, отлично подходит при отсутствии пункта 3.4, пример:
3.6 Спасибо Armando . В форме можно переопределять обработчики на свои, а из своих в нужный момент вызывать типовые. Тогда в большинстве случаев процедуры-обработчики событий можно смело заменять и даже дописывать в них ничего не придется:
4. Если необходимо изменить форму:
4.1. Описываем все изменения в процедуре " НеТиповыеИзменения " см. 3.4.
4.2. Кнопки и поля формы возможно добавлять программно, как и настраивать их первоначальную видимость/доступность.
5. Спасибо unichkin. Внедрения стандартов разработки (например: Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8 . ), позволит быстрее воспринимать код другого программиста.
Ссылки по теме (для меня это lvl-up, можно рассматривать как продолжение статьи):
Готов выслушать критику, советы по улучшению статьи как с точки зрения содержания, так и с точки зрения оформления.
Внес дополнения по комментариям от авторов unichkin, Armando , ИНТЕГРА
Уточнил пункт 3.4
Версия 1.2: добавил ссылку по теме для обычных форм. и пункт 5.
Специальные предложения
Все верно написал, не подкопаться! Делаю точно также и живу спокойно :) ТОлько я с 4.1 гораздо проще обхожусь - вношу в справочную информацию к своей подсистеме все доработки. Там тоже соблюдаю определенный формат.
(2) ИНТЕГРА, Смы(6) unichkin, К сожалению не нашел статей по "мягкой" доработке. Кидайте ссылку обязательно добавлю в статью.
(7) Armando, можно и так - но это затрагивает область программы. И как раз на этом методе основана статья из первой ссылки. ИМХО (6) - как то нагляднее, но это конечно только мое мнение :)
(12) unichkin, за статьи спасибо! Жалко, что только для управляемых форм подходит.
(13) unichkin, не согласен. Знакомился со стандартами и методиками от 1С. В них в основном описано как писать код, называть процедур и пр., но в задачи стандарта ни как не входит цель по минимизации времени обновления доработанной типовой конфигурации.
(14) "Жалко, что только для управляемых форм подходит." - неправда ваша. Две статьи, одна для обычных, другая для УФ. В задачи стандарта входит минимизация времени понимания одним кодером "дампа подсознания" другого. А это тоже влияет на время обновления :) Никакие ухищрения не помогут и не спасут, если двое делают "хорошо", но каждый по-своему.
//
Для объектов - дополню:
- ни в коем случае НИКОГДА не трогать именования типовых реквизитов, это очень пагубно сказывается на времени сравнения\объединения, я уж не говорю про разработку
- Все добавленные объекты переносить вверх соотв. ветки дерева метаданных - это во-первых оч. удобно при разработке - свои объекты всегда сверху, во вторых при том-же сравнении объединении будет меньше типовых в которых "Порядок объекта изменен"
- После обновления неплохо выполнить сравнение с конфой поставщика и убедиться что нет артефактов вроде "Справочная информация". Т.е. все изменения которые покажет сравнение должны быть понятны.
На счет п.3.4. не совсем понял. Можно поподробней?
Для изменения формы использую следующий подход: делаю копию типовой и вношу туда все изменения. Новая форма открывается с помощью подписки ДокументаМенеджера на событие ОбработкаПолученияФормы.
(3) Astafan, при сравнении двух модулей не понять, какие процедуры были изменены в типовой а какие просто обновление, для этого создается процедуоа где указываются все измененные процедуры.
(3) Astafan, На счет копии типовой формы, появится необходимость отслеживать, что в ней поменялось, что-бы перенести на копию, как боритесь с такой проблемой? Или создание копии типовой равносильно снятию типовой с поддержки?
"3.4" может стать узким местом, когда над конфигурацией работают разные люди. Все не заставишь где-то еще описывать внесенные изменения.
(4) Armando, тоже верно. Добавлю аргументов в мою пользу: это можно рассматривать как требования от Заказчика, что-бы не перетереть изменения от исполнителей, особенно, когда их несколько и исполнитель не выполняет обновление.
Уже давно есть подходы по "мягкой" доработке типовых - все описано на инфостарте. В тех случаях, когда доработка разовая - пригодится эта статья. От себя лишь добавлю, что желательно не просто комментировать код, а выносить изменения в отдельные блоки. Например - нужно доработать обработчик "ПриОткрытии". Не надо лепить код непосредственно туда - создайте буферный вызов, поместите его в самый конец модуля, и работайте в нем! Т.е. вот так:
Что это дает? То, что при обновлении конфы - если будет изменена типовая процедура в режиме сравнения объединения при объединении модулей можно смело ставить галку напротив типовой процедуры. Она будет перезатерта, ну и что - ведь конце модуля остался наш буферный вызов, из названия которого сразу ясно и понятно куда его нужно вставить! Кроме этого - сразу видно какие процедуры были изменены, и это очень удобно - не надо тратить драгоценное время на просмотр всего модуля. Тут конечно есть свои нюансы - если нужно сделать пару изменений в разных частях процедуры например. Я в таких случаях ВЕСЬ текст исходной процедуры выношу в блок "Удаленные фрагменты кода" (уфк_ПриОткрытии()), в типовой процедуре ставлю комментарий "Фрагмент изменен" - и опять вызываю свой буферный обработчик. Т.е. получается так:
уфф. увлекся)) Сопровождал несколько обновляемых конфигураций на упр. формах где использовал такой подход, - очень удобно.
(6) unichkin, в форме можно переопределять обработчики на свои, а из своих в нужный момент вызывать типовые. Тогда в большинстве случаев процедуры-обработчики событий можно смело заменять и даже дописывать в них ничего не придется:
(6) unichkin, Пункт 3.4 как раз нужен что-бы случайно не перезатереть типовые процедуры. Уточнил описание пункта.
(11) "чего, собственно, нигде не встречал" - ключевой момент, к сожалению. Все ведь уже придумано до нас, но об этом либо не знают, либо на это кладут. По крайней мере мой опыт говорит так. И ладно бы инфостарт - ведь есть замечательный ресурс ИТС, библия каждого 1С-ника, особенно начинающего. До кучи кину-ка я ссылку вот еще на это:
Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8 .
з.ы. Для тех, кто лишен доступа к ИТС существует недельный тест-драйв - это я на всякий.
Добавлю свои 5 коп. Как убедиться, что измененную конфигурацию обновили успешно и ничего не отвалилилось?
Итак, после обновления у нас есть 4 cf-ника:
- ПоставщикСтарая - старая конфигурация поставщика;
- ПоставщикНовая - новая конфигурация поставщика - та, на которую обновляем;
- ОсновнаяСтарая - измененная конфигурация, по сути это ПоставщикСтарая с нашими изменениями;
- ОсновнаяНовая - то, что получилось после обновления ОсновнаяСтарая с помощью ПоставщикНовая.
Теперь в двух конфигураторах сравниваем попарно:
- ПоставщикСтарая и ПоставщикНовая ;
- ОсновнаяСтарая и ОсновнаяНовая .
Для каждого сравнения конфигураций формируем полный "Отчет о сравнении объектов. " (для всех объектов конфигурации) в формате "Подробно", с подчиненными объектами метаданных (см. cmp.jpg) и сохраняем эти отчеты в текстовые файлы. Эти два текстовых файла сравниваем с помощью любой сравнивалки текста (я использую WinMerge). Так вот не считая технической информации, такой как номера строк с изменным/удаленным кодом и т.п., эти файлы НЕ ДОЛЖНЫ ОТЛИЧАТЬСЯ! Потому что оба отчёта показывают одно и то же - разницу, которую добавила в конфигурацию 1С.
После этого сравниваем попарно:
- ПоставщикСтарая и ОсновнаяСтарая ;
- ПоставщикНовая и ОсновнаяНовая .
Аналогично сохраняем отчеты о сравнении в текстовые файлы и сравниваем эти текстовые файлы. Они тоже НЕ ДОЛЖНЫ ОТЛИЧАТЬСЯ! Потому что оба отчёта показывают одно и то же - разницу, которую добавили в конфигурацию мы.
Если что-то отличается (помимо технической информации) - значит или не накатили какое-то изменение из типовой, или затерли какое-то свое изменение.
P.S. Чтобы убрать из отчетов о сравнении неинформативный хлам (такой как номера строк с изменным/удаленным кодом и т.п.), можно выполнить в текстовых файлах с отчетами следующие замены по регекспам:
1. Заменить что: ^(\s*)Объект присутствует только в(.+) конфигурации: \d+ - \d+$
Заменить на что: $1Объект присутствует только в$2 конфигурации: N - N
2. Заменить что: ^(\s*)Изменено: \d+ - \d+$
Заменить на что: $1Изменено: N - N
P.P.S. Если кому нужно - могу выложить эти замены в виде макроса для Notepad++
В своих разработках использую все рекомендации из статьи, только допёр до них самостоятельно. Дополню:
1) Во многих типовых конфигурациях в процедуре "ПриСозданииНаСервере" часто используется вызов какой-либо процедуры из общих модулей, куда передаётся "ЭтотОбъект" или "ЭтаФорма", например, ОбщегоНазначения.ПриСозданииНаСервере(ЭтотОбъект, Отказ, СтандартнаяОбработка). Я добавил в вызов из этой процедуры вызов своей процедуры "ПриСозданииНаСервере" в своём общем модуле, где в зависимости от переданой формы (определяется по ЭтотОбъект.ИмяФормы) вношу свои изменения на форме, например программно добавляю реквизиты формы, меняю условное оформление, добавляю кнопки, переопределяю стандартные действия и прочее. Соответственно изменений в самой форме нет, даже нет необходимости снимать с поддержки.
2) для добавления предопределённых элементов можно использовать дополнительный справочник "ПредопределённыеЭлементы", с одним лишь реквизитом "Значение", имеющий тип значения "Любая ссылка", соответственно можно к нему и через код и через запросы обращаться, получая значение из соответствующего реквизита, например, "Справочники.ПредопределённыеЭлементы.Контрагенты_ОсновнойКонтаргент.Значение" - вернёт заранее заданный элемент справочника контрагенты Или в запросе через соединение с этим справочником используя конструкцию "Значение()" в условиях к справочнику "ПредопределённыеЭлементы".
Рассмотрим задачу, когда нужно обновить типовую конфигурацию, в которую внесены изменения. Рассмотрим на примере конфигурации ЗУП, в которой в документ НачислениеЗарплаты был добавлен новый реквизит пр_ВнутреннийНомер. Предварительно необходимо установить файл нужного обновления.
Открываем конфигурацию в режиме Конфигуратор. Переходим в меню Конфигурация – Поддержка – Обновить конфигурацию (рис. 1):
Рис. 1. Обновление конфигурации
В открывшемся окне Обновление конфигурации выбираем Поиск доступных обновлений (рис. 2)
Рис. 2. Выбор источника обновления
Нажимаем Далее (рис. 3):
Рис. 3. Выбор области поиска файлов обновлений
Далее выбираем обновление и нажимаем Готово (рис. 4):
Рис. 4. Выбор обновления
Т.к. была отмечена галочка Показывать конфигурации (рис. 4), открывается окно с информацией про обновление, нажимаем Продолжить обновление. В следующем окне нажимаем ОК (рис. 5):
Рис. 5. Обновление
Далее открывается окно Обновление Основная конфигурация – Новая конфигурация поставщика, оставляем отмеченными все галочки (это значит, что обновляем все возможные объекты). Находим наш измененный документ НачислениеЗарплаты (рис. 6):
Рис. 6. Документ НачислениеЗарплаты
В документ НачислениеЗарплаты ранее нами был добавлен реквизит пр_ВнутреннийНомер и этот новый реквизит был выведен на форму документа. Снимаем галочку у реквизита пр_ВнутреннийНомер (рис. 6), это значит, что мы собираемся оставить этот новый реквизит в конфигурации. Далее посмотрим изменения в форме документа (ранее мы только добавили новый реквизит на форму, но в обновлении могут быть и другие изменения формы): правой кнопкой мыши по Форма – Показать различия в модулях… (рис. 7):
Рис. 7. Различия в модулях
Открывается окно Сравнение модулей, в котором в обновлении видны изменения в нескольких процедурах формы документа (рис. 8):
Рис. 8. Изменения в обновлении модуля формы документа
Т.к. ранее мы только добавили вывод нового реквизита на форму, то проще обновить форму, а затем заново вывести новый реквизит на форму. Для этого закрываем окно Сравнение модулей, оставляем галочку у Формы в окне Обновление Основная конфигурация – Новая конфигурация поставщика и нажимаем Выполнить (рис. 9):
Рис. 9. Выполнить обновление
На вопрос отвечаем Да (рис. 10):
Рис. 10. Вопрос при обновлении
В следующем окне нажимаем ОК (рис. 11):
Рис. 11. Окно при обновлении
Запускается процесс обновления объектов конфигурации. После выполнения объединения появляется окно, нажимаем ОК (рис. 12):
Рис. 12. Объединение завершено
Теперь нужно вернуть новый реквизит на форму документа, т.к. мы обновили форму из новой конфигурации поставщика, в которой нашего реквизита нет. Для этого открываем форму документа НачислениеЗарплаты, находим наш реквизит пр_ВнутреннийНомер и перетаскиваем его мышкой в группу ГруппаКомментарийОтветственный (рис. 13):
Рис. 13. Добавление реквизита на форму документа
Теперь форма документа обновлена правильно: мы внесли новые изменения поставщика, установив галочку в окне Обновление Основная конфигурация – Новая конфигурация поставщика (рис. 9), и вернули наше изменение формы – добавили наш реквизит пр_ВнутреннийНомер на форму документа (рис. 13).
Далее сохраняем конфигурацию: Конфигурация – Сохранить конфигурацию и обновляем конфигурацию базы данных: Конфигурация – Обновить конфигурацию базы данных (рис. 14):
Рис. 14. Сохранение конфигурации
При обновлении конфигурации базы данных появляется окно Реорганизация информации, нажимаем Принять (рис. 15):
Рис. 15. Принятие изменений при обновлении конфигурации базы данных
После завершения процесса обновления в Конфигураторе запускаем конфигурацию в режиме Предприятие и завершаем процесс обновления.
Подписывайтесь на канал
«Полезный 1С»
В телеграм канале — наш практический опыт, бизнес-кейсы и способы повышения эффективности компании, которые мы опробовали внутри группы Neti.
Чтобы система была стабильной и всегда работала, важно вовремя её обновлять. Но часто после обновлений что-то перестает работать. Доходит до того, что пользователи панически боятся обновлений и стараются обновляться как можно реже. Эта практика не лишена здравого смысла, но имеет существенные недостатки.
Поломанные функции раздражают: однажды сделали доработку, проверили её со всех сторон, а после обновления она перестаёт работать. Почему так происходит, даже если обновлениями занимается хороший квалифицированный специалист?
Текст объемный, потому что мы рассматриваем проблему с разных сторон. Со статьёй можно погрузиться в тему и сделать управленческие выводы. В статье много терминов, но мы постарались всё перевести на понятный язык.
Три основных типа доработок в 1С
На вопрос «зачем вообще делать доработки в 1С» нужен большой развёрнутый ответ. Если коротко — доработки помогают улучшить систему и получить преимущество по сравнению с другими компаниями.
Вариантов доработок много: есть более «стойкие», есть менее, есть хорошая практика доработок, есть плохая. Попробуем разобраться в плюсах и минусах различных вариантов, а также попробуем понять, почему они перестают работать и как снизить вероятность появления ошибок.
Сделать доработку так, чтобы она гарантированно не слетала после обновлений — невозможно.
-
Доработки 1С могут быть такими:
- Внешние доработки: печатные формы. отчеты и т.д.
- Расширения
- Изменения кода типовой конфигурации
Внешние доработки: внешние обработки, отчеты и т.д.
1С — сильная система, в которой многие процессы автоматизированы, но часто пользователи просят доработать программы чуть-чуть, по мелочи:
- разработать специфические отчёты, которых не хватает
- доработать или написать новые печатные формы с нужной информацией и оформлением
При этом обновление самой конфигурации при наличии таких доработок — простейший процесс, который можно сделать даже без участия человека.
Почему могут не работать после обновлений?
Такой способ доработки — один из самых стабильных. Проблемы появляются, если разработчики типовой конфигурации, которую мы и обновляем, что-то поменяли в своих механизмах. Но то, что может поломать внешние доработки, меняется не часто.
Как избежать ошибок?
Способ есть один и он универсальный для каждого варианта доработки системы. И он довольно простой — после обновлений нужно просто проверить каждую доработку. Как бы это ни звучало просто, возникает много нюансов и вопросов.
Когда возникают проблемы?
По сути, внешние доработки это множество мелких доработок, отдельных программных модулей.
Проверить код каждой доработки даже минимальным встроенным синтаксическим контролем, который проверяет самый минимум, огромная задача. Нужно открыть каждую разработку и запустить синтаксический контроль. Таких доработок может быть много, а проблемы возникают не часто.
Получается дилемма: либо открывать каждую разработку и проверять синтаксическим контролем и работой в пользовательском режиме, тратить на это много времени и, как правило, денег заказчика, либо ничего не проверять.
Что на самом деле делает программист при обновлении?
Обычно, программисты выбирают вариант ничего не проверять. Этот вариант и является оптимальным. Ошибки исправляются по обращениям пользователей (да, получается, что тестируют конечные пользователи). Но искать ошибку не надо, она уже найдена, обычно довольно понятна и может быть быстро исправлена.
Как снизить затраты на поддержку доработок?
Как раз для снижения затрат обычно и выбирается вариант — делать все без проверки. Если реально все проверять каждое обновление (и делать его раз в месяц), то затраты получатся большими, а проблемы встречаются нечасто.
Как повысить стабильность доработок?
Все внешние разработки поделить на критичные и некритичные. Критичные обычно влияют на оперативную работу компании. Например, если при ошибке в доработке остановится выписка документов, это повлияет на финансовые результаты компании.
Для проверки таких критичных доработок можно выделить опытного пользователя, который будет тестировать всё. Ещё один вариант — договориться об этом с вашей обслуживающей компанией.
Расширения: новое слово в доработках 1С
Расширения позволяют точечно дорабатывать 1С: делать заплатки в отдельных документах, добавлять нужные кнопки или писать целые подсистемы — новые функциональные блоки у программы. Доработки выполняются менее «инвазивным» способом и позволяют контролировать изменения основной конфигурации. Если изменение произойдет, разработчику будет выдано соответствующее предупреждение.
Многие пользователи, которые знакомы со значительными доработками 1С (особенно с горьким опытом предыдущих систем), знают понятие «конфигурация должна быть на замке». Это значит, что доработки выполняются внешними модулями, а ваша конфигурация останется нетронутой. С этой точки зрения расширения похожи на внешние доработки из прошлого пункта.
Расширения появились достаточно давно, но не все программисты их используют. Мы советуем присмотреться к этому механизму: он прост в использовании, не меняет основную конфигурацию 1С и помогает быстро добавлять нужные функции.
Почему могут не работать после обновлений?
Причина все та же (она будет всегда одинаковой) — код вашей конфигурации поменяли разработчики типовой конфигурации 1С, а доработки на него опирались, поэтому перестали работать.
Как избежать ошибок?
Конечно, тут опять же нужно все проверять после каждого обновления. Но сделать это уже труднее. Расширения позволяют поменять много разных мест в программе, и сразу далеко не очевидно, где именно и что проверять.
Когда возникают проблемы?
В двух основных ситуациях:
доработки в расширениях сделаны неправильно (про это позже)
у вас установлено много расширений
Можно создать стандарты доработки расширений, мы работаем именно так. Стандарты помогают сократить частоту поломок после обновлений, но не избежать их на 100%.
А если устанавливать множество расширений, один и тот же участок программы может быть доработан в разных расширениях. Тогда расширения могут конфликтовать друг с другом, превращая доработки в сложнозапутанный клубок. Например, одну и ту же печатную форму доработали разными расширениями. Доработки конфликтуют, и после обновления форма не работает.
Решение в этой ситуации - уменьшить количество расширений. Это облегчит и поддержку, и развитие.
Что на самом деле делает программист при обновлении?
Сама 1С обновляется легко, она же «на замке».
После обновления обязательно проверяется совместимость расширений с текущей версией программы.
Получается, не нужно проверять множество разных доработанных внешних программных модулей, а можно проверить всё в одном месте.
Спасает ли это на 100%? Нет, без «пользовательского тестирования» все равно не обойтись. Несмотря на то, что грамотно написанные расширения гораздо стабильнее, чем исправление внутри самой конфигурации, и много проблем позволяют выявить в автоматическом режиме.
Как снизить затраты на поддержку доработок?
Для сокращения издержек разработчик и в этом варианте не проверяет «пользовательскую» работоспособность. Иначе поддержка выходит опять же слишком дорогой.
Исправляются проблемы автоматической проверки совместимости, а остальное — по обращениям пользователей.
Как повысить стабильность доработок?
В первую очередь нужно, чтобы разработчики создавали расширения по стандартам и грамотно их использовали.
Если простой для вашей компании критичен, а в программах 1С много расширений, можно обновлять не рабочую базу, а её копию. После обновления копии ваш пользователь или подрядчик тестируют критичный функционал. Если всё в порядке, обновляете рабочую базу с обновлёнными расширениями.
Изменения кода типовой конфигурации
Доработка самой конфигурации — серьёзный шаг. Чтобы её дорабатывать, нужно понимать, зачем, почему и какие сложности будут с обновлениями. Обновляет доработанную конфигурацию программист. При этом важно отслеживать все изменения и не затереть код прошлых изменений.
Именно при доработанной конфигурации сложнее всего обновлять программы, и это вызывает страх у пользователей.
Важно отличать случаи, когда действительно нужно дорабатывать конфигурацию, а когда можно обойтись внешними доработками или расширениями. Обычно менять конфигурацию не нужно в случаях с печатными формами, кнопками.
Например, у вас есть документ Счёт на оплату. В него нужно добавить кнопку «Дать скидку до минимальной наценки». Для решения этой задачи не надо менять конфигурацию, достаточно написать внешнее расширение.
Если изменить типовую конфигурацию там, где можно этого не делать, плюсов от внешних доработок не будет. Но гарантированно будет головная боль от обновлений.
Существует и «полностью добавленный функционал» — отдельно стоящие подсистемы, которые не опираются на типовой код конфигурации и обновление его практически не затрагивает. Но все же большинство доработок обычно касаются именно функционала типовой конфигурации.
Почему могут перестать работать после обновлений?
Причина одна: что-то поменялось в конфигурации поставщика. И последствия тут могут быть сложнее, чем в случае с внешними доработками.
Если в каких-то местах ваш программист изменил код, то изменения от разработчиков 1С могут войти в конфликт с этими изменениями. В этом случае изменения вашего программиста стираются — код заменяется на типовой. Поэтому программисту, который обновляет доработанные конфигурации, нужно вручную отследить изменения и перенести их в новую конфигурацию. При этом важно не потерять изменение: человеческий фактор влияет максимально.
Хорошая практика — комментировать любое именение типового кода, описывать места изменений. Но и это спасает не всегда.
Как избежать ошибок?
Главное — не менять конфигурацию, если доработку можно сделать без этого. Если без изменений никак не обойтись, и это подтверждает грамотный программист, нужно доработать программу аккуратно, добавить пометки об изменении кода прямо в нём.
В таких случаях проверить все изменения и как они влияют на вашу программу проблематично. Даже если сравнить построчно типовую программу и вашу, доработанную, нужно долго разбираться что и зачем было изменено.
Как обычно, избежать поломки может только тотальная проверка всех мест, которые гипотетически могут поломаться, но их может быть очень много. И нужно потратить крайне много сил на исправление и подготовку теста.
Когда возникают проблемы?
В общем случае всегда. Практически любое изменение стандартного кода влечет повышенную сложность сопровождения вашей 1С. Дальше все зависит от квалификации и внимательности программистов, которые вносят изменения в программу и (в большей степени) обновляют её.
Что на самом деле делает программист при обновлении?
-
Основная задача программиста при обновлении такой 1С — постараться не потерять изменения:
- отметить места, которые слетели
- вручную перенести затертый код
- проверить, не выдает ли программа ошибку при запуске
А если разработчики внесли много изменений в типовую конфигурацию, или вы долго не обновляли свою базу, сложность всех этих процедур усложняется многократно.
Обычно на все эти процедуры уходит много сил и внимания разработчика, и о глобальной проверке «пользовательской работоспособности» уже никто не думает: она может занять намного больше времени, чем само обновление.
Как снизить затраты на поддержку доработок?
Избегать доработок внутреннего кода в тех случаях, когда это делать не надо, этим часто грешат начинающие программисты.
Если пришлось дорабатывать «по живому», то опять же самый простой и дешевый сценарий — это давать обновленную базу пользователям и в случае ошибок стараться оперативно исправлять. Однако частота возникновения ошибок уже довольно существенная.
Как повысить стабильность доработок?
-
Тут много направлений:
- Работать над качеством разработки и комментирования кода.
- Если доработки ведутся несколькими программистами, налаживать коммуникацию и правила доработок.
- Вести документацию по обновлениям, фиксировать места, которые точно нужно проверить после обновления.
- Обязательно обновлять вначале копию, а потом уже рабочую базу.
- Составить чек-лист проверок критичного функционала и договориться, кто его будет проверять. В идеале нужно на копии базы подготовить примеры (тест-кейсы) по которым кто-то будет обязательно проходить и только после теста разрешать обновлять рабочую базу.
- Следить, чтобы тест-кейсы были не просто составлены, но и полностью проверялись. Если пользователи не проверяют обновлённую копию или просто делают там пару кликов, проверка не сработает.
Подытожим
- Дорабатывать 1С можно тремя основными способами: внешними доработками, расширениями и изменениями типовой конфигурации.
- Важно выбирать способ доработки исходя из целей, сложности поддержки и затрат.
- Нужно стараться использовать расширения, они не меняют типовую конфигурацию и создают меньше сложностей при обновлении.
- Разработчики проверяют работоспособность кода, синтаксические ошибки в нём. Но программисты не отратабатывают пользовательские сценарии.
- «Проверить, чтобы все работало», к сожалению, невозможно и нецелесообразно, но можно составить чек-лист критических проверок.
- Сама проверка функционала в «пользовательском режиме» — очень непростая задача, затратная, иногда, кажется, что бессмысленная: если проверяем уже 3-е обновление подряд, ничего не ломается, а времени тратится много.
- Нужно писать тест-кейсы, по которым реально проверить работу критического функционала.
- Важно следить, чтобы ответственные пользователи проверяли критический функционал: это снижает количество ошибок в дальнейшем.
А что делать, если хочешь дорабатывать 1С и испытывать меньше головной боли?
Автоматическое тестирование — инструмент, кторый помогает дорабатывать 1С. Автоматическое тестирование позволяет с одной стороны получать новые нужные функции, а с другой — не сталкиваться с постоянной поломкой критического функционала на рабочей базе.
Это сложный способ, но он помогает держать систему в рабочем состоянии и избегать простоя в важной работе. О том как это все устроено, и какие есть плюсы и минусы, разберемся в следующей статье.
Автотесты мы используем на собственных разработках и планируем внедрять автоматические тесты клиентам, чтобы повысить качество сопровождения программ 1С.
Читайте также: