Как поменять типовые условия в 1с

Обновлено: 07.07.2024

Для средних и крупных предприятий типовые конфигурации 1С часто требуют значительных доработок под особенности ведения различных видов учетов на данных предприятиях. Внесение большого числа изменений со временем ведет к значительному увеличению времени подготовки обновлений, а в ряде случает и невозможности обновлений таких конфигураций. Хорошо, если в такой базе ведется только, например, торговый учет, который менее чувствителен к изменению законодательства, но, если в одной базе ведется и полный бухгалтерский и налоговый учет с нормальным расчетом заработной платы, то картина становится менее радужной. Можно ли, все-таки, сохранить разумные трудо-временные затраты при обновлении таких баз? Я думаю, что это возможно при соблюдении некоторых рекомендаций при внесении изменений в конфигурации, хотя, рано или поздно, может возникнуть такая ситуация, когда придется переходить на новую версии базу, перенося остатки.

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

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

Общие правила внесения изменений объектов конфигурации:

создавать собственные объекты конфигурации, минимально изменяя типовые и предварительно изучив методику и работу типовых объектов;
Вновь создаваем объектам, реквизитам, формам, макетам, значениям перечислений, предопределенным элементам и т.п., а также процедурам, функциям и переменным присваивать свой собственный префикс или постфикс, например, «гу» (мне больше нравится префикс);
Не следует изменять порядок следования типовых объектов конфигурации, чтобы потом при обновлении конфигурации не получить неоправданно большой список измененных объектов, который придется внимательно просматривать;
Не следует удалять типовые объекты конфигурации, элементы форм и табличных частей, элементы стиля, картинки и т.п.
Доработки, касающиеся заполнения табличных частей желательно производить с помощью внешних обработок (для заполнения табличный частей) и подключать их к документам с помощью справочника «Внешние обработки»;
Дополнительны печатные формы также правильно разрабатывать как внешние и подключать через справочник «Внешние обработки»;

Особенности изменения ролей (роли в 1С имеют приоритет доступа над запретом и доступ к объектам и реквизитам формируется через сложение набора предоставляемых ролей):

По возможности не нужно изменять типовые роли, а лучше добавлять новые: либо на основе типовой и отразить это в имени роли, либо как дополнительную к уже имеющейся типовой роли, но «раздающую» права на добавленные нами объекты конфигурации;
При настройке вновь создаваемых ролей лучше придерживаться правил создания ролей для типовых конфигураций – это установка галочек для роли «Устанавливать права для реквизитов и табличных частей по умолчанию» и «Независимые права подчиненных объектов», если у вас, конечно, нет каких-то ОЧЕНЬ весомых аргументов простив установки этих галочек. Если вы вдруг создаете свою роль с полными правами, то удобно установить галочку «Устанавливать права для новых объектов», НО следует помнить, что интерактивная роль «Интерактивное удаление» также будет устанавливаться для новых объектов по умолчанию (!) и ее нужно будет снять вручную.
Бывает, что требуется забрать права на некоторые объекты у типовой роли, например, «Пользователь» - такие действия должны иметь серьезное обоснование и следует понимать, что это значительно увеличит время обновления ролей – нужно будет каждый раз сравнивать эту роль и вручную настраивать доступ по объектам. Как альтернатива предложенного решения можно рассмотреть создание, например, регистра сведений, по записям которого мы будем определять доступ к объектам конфигурации того или иного пользователя, но это требует написания значительного объема кода.

Особенности изменения интерфейсов:

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

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

Изменение форм:

Не следует изменять типовые формы, непосредственно изменяя элементы формы – очень многое можно легко добавить программно, обработчики новых элементов формы также могут быть описаны программно. В случае же, если форма требует значительных изменений и сделать их все программно становить ОЧЕНЬ сложно, то можно копированием создать свою форму добавив к ней, например, префикс «гу» и выбрав ее основной формой объекта. При этом удобно код типовой и вновь созданной форм держать одинаковым, а изменения на форме делать только для вновь созданной – это позволит снизить временные затраты при подготовке обновлений таких объектов.

Изменение макетов:

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

Изменение подсистем:

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

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

Изменение кода модулей:

Общеизвестно правило, что свой код нужно комментировать. Можно разработать собственные маркеры кода и разместить их в шаблонах текста. Пример:

//@@@ Код до изменения: |

И шаблон комментирующий новый блок кода:

Подобный шаблон удобен потому, что легко искать свои изменения по строкам «@@@» или имени пользователя, причем зная примерно год или месяц внесения изменений и добавив их с троку поиска легко получаем ссылки на измененные строки. Простановка даты в комментариях видится скорее плюсом – всегда легко определить период внесения изменений и в случае изменений методологии 1С для типовой конфигурации можно понять необходимость глубокого анализа ранее сделанных изменений.

Удобно сделать разные комментарии для нового кода и для измененного, отдельно обрамлять комментариями добавляемые процедуры и функции. Общие процедуры и функции следует выносить, по возможности, в свои, специально созданные, общие модули, именованные, например, с префиксом «гу». В типовые общие модули изменение нужно вносить по минимуму, желательно ограничиваясь только точкой входа во вновь созданные процедуры.

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

Для частей кода, требующего доработки, и кода «заглушек» удобно придумать свой комментарий, по которому легко было бы находить эти строки, НО, как известно, ничего не бывает более постоянного, чем временное.

Обработчики событий изменить не всегда удастся, но возможно организовать перехват обработчиков событий форм с использованием оператора Выполнить (примерно как опсано здесь:

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

Все примеры в этой статье сделаны на конфигурации «Управление нашей фирмой», у которой я включил возможность изменения всех объектов, оставив при этом её на поддержке. Определим некоторые условности: типовым я буду называть объект поставщика, который не был изменен. После того, как этот объект поменяли, он уже стал нетиповым.

Порядок объектов 1C

Первое, я не рекомендую изменять порядок объектов.

К пример, был такой порядок:

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

Этот фильтр, по сути, показывает изменения, которые мы внесли в конфигурацию, и сдвинутые таким образом объекты будут нам мешать работать с остальными объектами.

Снятие с поддержки и удаление

Желательно, не снимать с поддержки объекты поставщика, и тем более удалять их. Потому что, если мы снимем с поддержки какой-то объект, например этот справочник.

То во время обновления, этот объект по умолчанию не будет обновлен, т.е. он не примет все те изменения, которые присутствуют в новом релизе поставщика. И в окне «Сравнить, объединить», которое появляется во время обновлений баз, у которых поддержка с возможностью изменения

Новые методы в общем модуле поставщика

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

Если мы создадим в общем модуле поставщика свою процедуру или функцию.

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

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

Тогда во время обновления, не придётся выполнять работы по совмещению изменений поставщика и ваших изменений в общем модуле.

Переименование объектов, процедур и функции 1С

Не рекомендуется переименовывать объекты, процедуры и функции поставщика. Потому что, во время обновления придется контролировать, чтобы эти измененные методы не были затерты методами поставщика.

Например, переименуем в общем модуле функцию, а также вызов этой функции в другом методе.

Во время выполнения обновления конфигурации, этот модуль, где мы переименовали метод, появится в окне «Обновление Основная конфигурация – Новая конфигурация поставщика» причем с установленным фильтром «Показывать только дважды измененные свойств».

Если мы посмотрим, что изменилось.

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

С одной стороны, ни чего страшного: все вернется, как было. Но, тут возможны нюансы: первое, если мы что-то доработали в нашем методе с измененным названием, то эти доработки пропадут; второе, если мы используем метод с измененным названием где-то, например, в нашем общем модуле то его вызов таким и останется, как мы написали, что приведет к ошибкам.

Доработка методов модулей поставщика

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

Например, в общем модуле ОбщегоНазначения нужно доработать процедуру «МестоположениеКомпонентыКорректно».

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

И её уже вызовем в процедуре общего модуля поставщика.

Копирование методов поставщика с последующей доработкой

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

Например, в этом случае, вместо процедуры «МакетСуществует» модуля поставщика.

Можно создать копию этой процедуры в своем общем модуле

Эту копию изменить как надо, а потом поменять вызов типовой процедуры.

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

Изменение подсистем 1С: создать подчиненную

Если вы создали какой-то объект, то его желательно нужно добавить в подсистему. Рекомендую воздержаться от изменения типовой подсистемы, и создать собственную подсистему, в состав которой добавлять новые объекты.

Иногда такое не всегда приемлемо, потому что новый объект нужно включить в видимость какой-то подсистемы поставщика. Если добавить объект в саму подсистему поставщика.

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

Чтобы каждый раз при обновлении не тратить время на совмещение составом, лучше создать свою подсистему, которая будет подчинена подсистеме поставщика.

И в эту подсистему включить ваш новый объект.

Тогда вам не придется при обновлении каждый раз работать с составом типовой подсистемы.

Изменение типовых форм

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

Если изменения значительны, то стоит создать новую форму копию типовой с префиксом, и добавить её в основные формы объекта. Но этот вариант спорный, потому что если вы измените типовую форму то при обновлении вы увидите, что форма поменялась, а в случае своей формы, вы это не узнаете, и можете пропустить критичное изменение. Или в случае, когда создана своя форма, то при обновлении нужно будет каждый раз анализировать изменения типовой формы.

Как сохранить конфигурацию 1с

В результате у вас получится cf-файл, который вы или зальете в облако, или скопируете на флешку, и отнесете на свое рабочее место (домой или в офис).

Как загрузить конфигурацию 1с

После того, как вы придете на свое рабочее место, необходимо создать пустую базу. Делается это достаточно просто.

В результате выполнения команды, откроется окно выбора файла с расширением cf, в котором вы выбираете ранее сохраненный у клиента cf-файл.

Включить возможность изменения конфигурации

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

Более подробно о поддержке конфигурации читайте в моей статье Поддержка конфигурации 1С.

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

А также включим для справочника Номенклатура и документа ЧекККМ c основной формой документа правило «Объект поставщика редактируется с сохранением поддержки»

Внести изменения в конфигурацию 1С

Изменим справочник Номенклатура, добавив в него реквизит.

А также документ ЧекККМ: добавим реквизит и поместим его на форму в виде элемента Поле.

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

Объединение конфигурации 1с

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

И здесь две рекомендации:

Обязательно сохраните базу клиента, перед тем, как вносить изменения;
~~Не используйте команду «Загрузить конфигурацию из файла».~~

Почему нельзя использовать команду «Загрузить конфигурацию из файла»? Потому что, если во время вашего отсутствия с клиентской конфигурацией что-то делали, то вы этой командой сотрете все ранее сделанные изменения.

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

Сравнение конфигураций 1С

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

После выполнения команды нужно будет выбрать, что с чем мы сравниваем.

И если мы сравниваем с конфигурацией из файла, то необходимо указать нужный cf-файл.

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

Возврат на поддержку измененной конфигурации 1С

Редко, но бывают случаи, когда снимают полностью с поддержки измененную конфигурацию 1С, если мы в этом случае поставим обратно на поддержку при помощи команды «Загрузить конфигурацию из файла», то все изменения сделанные ранее затрутся.

Чтобы сохранить изменения нужно использовать уже знакомую команду «Сравнить объединить с конфигурацией из файла».

Во время возврата на поддержку нужно выбрать cf-файл типовой конфигурации 1С.

После выбора файла типовой конфигурации, выйдет предложение поставить конфигурацию на поддержку.

После нажатия кнопки «Выполнить», появится окно с настройками правил поддержки для объектов, в этом окне оставим всё по умолчанию.

Конфигурация встанет на поддержку с возможностью изменений.

Но наша конфигурация еще не полностью на поддержке.

Для того, чтобы она стала полностью на поддержке, необходимо в окне «Настройка поддержки» у всех объектов конфигурации, которые были изменены установить правило «Объект поставщика редактируется с сохранением поддержки», а также у самой конфигурации. Если в вашей конфигурации все объекты должны быть на поддержке, то чтобы не ставить каждый объект отдельно, можно во время установки правила для всей конфигурации, поставить флаг «Установить для подчиненных объектов», тогда это правило для всех объектов конфигурации установится автоматически. Иначе нужно будет к каждому объекту отдельно применять это правило.

Статьи по теме обновлений 1С:

Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Научитесь понимать архитектуру 1С;
Станете писать код на языке 1С;
Освоите основные приемы программирования;
Закрепите полученные знания при помощи задачника.

Очень доступный и понятный язык изложения
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Поймете идеологию управляемого приложения 1С
Узнаете, как разрабатывать управляемое приложение;
Научитесь разрабатывать управляемые формы 1С;
Сможете работать с основными и нужными элементами управляемых форм
Программирование под управляемым приложением станет понятным

можно оплатить вручную:

Стандартный период в 1С – это общий объект, который можно использовать и при работе с управляемой формой, и при работе с компоновкой данных. В этой статье разберем, как работать со стандартным периодом на управляемой форме и в СКД.

Стандартный период в 1С на управляемой форме

На управляемой форме можно создать реквизит с типом Стандартный период, и поместить этот реквизит на саму форму в виде поля ввода.

Теперь, если пользователь нажмет на кнопку «…» поля ввода стандартного периода, то откроется окно «Выберете период».

В этом окне можно выбрать любой период, и поместить его в поле ввода.

Как нам, после того как будет выбран период, получить дату начала и дату конца периода? Для этого следует воспользоваться свойствами ДатаНачала и ДатаОкончания объекта СтандартныйПериод.

Напомню, что Период – это реквизит формы (см. первый скрин).

Стандартный период можно создать в коде при помощи конструктора Новый.

Если мы сделаем так, то создадим пустой стандартный период (с пустыми датами). Также можно создать стандартный период с уже заранее определенными датами.

Ещё, можно создать стандартный период по варианту. Например, создадим стандартный период вчерашней даты.

ВариантСтандартногоПериода – системное перечисление, которое содержит разные варианты стандартного периода. Посмотреть на все значения этого перечисления можно в синтакс-помощнике (Системные перечисления – Разные – Варианта стандартного периода).

Созданную при помощи конструктора Новый переменную типа СтандартныйПериод, можно, как вариант, присвоить реквизиту формы такого же типа.

Стандартный период 1С в СКД

Стандартный период можно использовать в СКД. Например, нам нужно получить список документов, начиная с одной даты и заканчивая другой датой.

У нас получится такой вот несложный запрос в наборе данных.

Со следующим набором параметров.

Если мы всё так и оставим, эти параметры у нас перейдут и в настройку.

И в форму отчета.

Возможно, вас такой вариант и устроит, а можно заменить эти даты стандартным периодом.

Для этого в схеме компоновки данных нужно создать параметр с типом СтандартныйПериод.

А в поле Выражение для параметров ДатаНачала и ДатаОкончания получать дату начала и дату окончания параметра с типом СтандартныйПериод:

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

Чтобы поле Период отобразилось на форме отчёта, следует установить свойство Включать в пользовательские настройки соответствующему параметру на закладке Настройки.

Ну и также, не забудем выбрать поля у детальных записей.

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

Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Научитесь понимать архитектуру 1С;
Станете писать код на языке 1С;
Освоите основные приемы программирования;
Закрепите полученные знания при помощи задачника

Очень доступный и понятный язык изложения
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Поймете идеологию управляемого приложения 1С
Узнаете, как разрабатывать управляемое приложение;
Научитесь разрабатывать управляемые формы 1С;
Сможете работать с основными и нужными элементами управляемых форм
Программирование под управляемым приложением станет понятным

Читайте также: