Общие рекомендации по внесению изменений в конфигурацию для последующего облегчения обновления.
Рекомендации по подписям, добавление реквизитов, модулей, форм, процедур...
Все мы не раз сталкивались с обновлением измененных конфигураций. Обычно это долгий и муторный процесс, и почти всегда что-то да теряется из функционала, который до этого старательно добавляли, особенно если это функционал добавляли не вы. Как с этим бороться? Как облегчить себе жизнь?
Вот несколько наработок и правил, которые в этом помогают:
1) Подписи.
Все мы обычно подписываемся так:
///Тима - Тима для примера, может быть вася петя инициалы итд
Но это не совсем верно: если в глобальном поиске набрать "Тима", то вылезет куча не нужных вещей, например "Функция дкПривестиМакетПечатнойФормы(ЭтотОбъект,Макет)". (Хотя можно искать и "/Тима"
поэтому лучше подписываться латинскими буквами!
Дальше нам надо, к примеру, изменить знак в строке)
Переменная = Переменная - 1; ///TIMA
Если мы подпишемся так, то это будет не очень ясно, а писать в комментарии, что конкретно изменил не всегда получается понятно другому человеку, поэтому лучше комментировать все строки, которые вы изменяете, а ниже уже писать свои:
И если вы изменяете целый блог то лучше еще вставить начало изменений и конец изменений.:
///Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///Tima -
Также если работает несколько человек над одной конфигурации, то перед именем в подписи вставьте что-то общее, например имя организации, для которой вы все это меняете:
///RogaAndKopita Tima +++ (а лучше и написать дату изменения, чтоб было легче вспоминать) 230813
///Переменная = Переменная + 1;
Переменная = Переменная - 1;
///RogaAndKopita Tima -
2) Подписки на события!
Ну конечно же во-первых и во-вторых используйте Подписки на события.
Порядок выполнения подписки на событие не регламентирован, пишите код исходя из этого.
3) Добавление реквизитов, модулей, форм итд
Все новые объекты конфигурации добавляете с префиксом (например, "Dop_" или "RogaAndKopita_" или "Tima_").
То же самое касается и новых функций или процедур.
4) Добавление новых процедур
Все новыее процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Старайтесь как можно больше процедур и функций помещать в СВОЙ общий модуль, вы себе этим здорово облегчите жизнь.
Если вы забудете, что вносили изменения и затрете свои или чужие наработки, то гораздо легче найти место, куда вставлять вызов процедуры, чем восстанавливать всю процедуру заново.
5) Изменения в формах.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Первый способ.
Если хотите изменить события формы или обработки реквизитов, то есть 2 способа
Процедура ДопПриОткрытии()
///Сюда вставляем что хотим до
Выполнить(допПолучитьСтароеДействиеФормы(ЭтаФорма, "ПриОткрытии"));
///Сюда тоже можно вставлять
КонецПроцедуры
Второй способ.
Позаимствовал у компании Рарус обработку реквизитов: в модуле формы во все требуемые процедуры пишем строчку:
///Если Обрабатываем ТабЧасть:
ОбработкаРеквизита("ИмяТабЧасти.ИмяРекизита", ЭлементыФормы.ИмяТабЧасти.ТекущаяСтрока, ЭтаФорма);
///Если обрабатываем реквизит формы или событие:
ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
А в модуле документа делаем:
Функция ОбработкаРеквизита(Имя,ТекСтрока=Неопределено,ЭтаФорма=Неопределено,ДопПараметры=Неопределено) Экспорт
Если имя = "ИмяРекизита" тогда
ИначеЕсли имя = "ИмяРекизитаДругого" тогда
//А если надо вызвать обработку другого реквизита при выполнении кода это делается легко:
возврат ОбработкаРеквизита("ИмяРекизита", , ЭтаФорма);
Иначе
//// А тут можно сделать вызов такой же функции в общем модуле для изменения общих реквизитов (например ставка НДС)
Возврат ДопОбработкаРеквизита(Имя,ТекСтрока,ЭтаФорма,ДопПараметры);
КонецЕсли;
КонецФункции
6) Изменение самой формы
Если нужно изменить саму форму, например добавить реквизит или еще что-то, можно использовать декомпилятор форм:
А код из декомпилятора вставлять в процедуру ПриОткрытии (конечно с учетом 5-го пункта)
А вот если требуется сильно переделать всю форму, то советую создавать новую форму, тогда при обновлении всего лишь переопределится форма по умолчанию, а все ваши изменения не потеряются.
Вот собственно и все приемы, которые я знаю. Если знаете еще способы, то пишите, обязательно их добавлю.
После года интенсивной работы в управленческой базе 1С накапливается большое количество информации. Алчные до анализа аналитики загружают разработчиков 1С большим объемом работ по созданию разных отчетов из базы данных. Это нужно, чтобы получить крупицы «золотой» информации, необходимой для принятия правильного управленческого решения. Как результат, загружены разработчики, нагружено железо, перегружены регистры, чешут голову администраторы по железу..... бюджет поддержки такой системы летит к небесам… Расскажем о том, как выгрузить данные из 1С в BI и передать настройку произвольных отчетов в руки аналитиков и юниор разработчиков, чтобы они сами могли вывести отчеты и взаимосвязи с помощью Yandex datalens.
На крупных проектах интеграции залогом успеха становится использование грамотных технических решений, инструментов и методик. Расскажем о совместном использовании «Конвертации данных 2» и 1С:Шины, подходах к интеграции НСИ, а также разделении труда в команде исполнителя.
В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.
Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.
1. Если меняется одна строка, то лучше писать комментарий в той же строке или перед ней.
Со временем таких изменений будет несколько и код может выглядеть как елка - всё зеленое от почти бессмысленных комментариев.
Да и причину писать надо. Бывает на одну строку кода пишешь 2-3 строки комментария.
Переменная = Переменная - 1; ///RogaAndKopita Tima +++ вместо "+" будет "-" потому что <причина действий> 230813
2. Все новые процедуры и функции добавляете в СВОЙ общий модуль, по возможности не трогайте типовые!
Частично согласен. Но я бы советовал не один модуль, а несколько. Разделить их, во-первых, по направлениям/участкам работы. Во-вторых, на клиентскую и серверную часть.
И не стоит скидывать со счетов модули менеджеров - очень полезная вещь, особенно, если функция или процедура работает только с одним видом объекта конфигурации.
3. Могу предложить еще вариант "триггеров" - некий справочник, в котором хранится код 1С, вызываемый в тех или иных случаях - динамическое изменение кода, универсальность встраивания.
Подписки хороши, если мы что-то делаем "по факту" и с целым объектом. А если нам надо в форме документа проверять реквизит на какие-то условия?
Если условий 5-10 штук, они меняются раз в месяц, да еще зависят от второй буквы девичьей фамилии матери отца соседа снизу пользователя?
Вот тут и пригодится такой внешний код - вызов займет 1-2 строки, при встраивании в типовую конфигурацию удобнее обновлять несколько строк, чем "километры" кода.
4. Для изменяемых объектов типовой конфигурации можно завести отдельную подсистему "ВрезкаВТиповую" и включать объекты в случае их изменения - это позволит в случае "врезок" либо исправления ошибок до выхода новой версии типовой фиксировать измененные объекты чтобы отслеживать их при обновлении.
1 пункт, если в типовые модули делать минимум изменений то как елка код не будет выглядеть, а в доп модулях комментировать все не обязательно.
2 пункт да, видно надо было расширить в статье это.
3 пункт получается аналог внешнего модуля, просто изменения можно внедрять не залезая в конфигуратор. Такой вариант тоже имеет право на жизнь.
Главное обновляй конфу поставщика нормально и все твои врезки будут видны и понятны ибо никакие комментарии не помогут понять, что же цензура сделали в этой конфе, где версия cf 3.0.2, а версия поставщика 1.0.1 ...
А такие комментарии нафиг не нужны, т.к. они больше похожи на написанное на заборе "Сдесь был Вася!" , "Выпуск 1986г."...
(105) Gazza, "завести отдельную подсистему "ВрезкаВТиповую"" - я пришел к выводу о том, лучше делать следующую иерархию подсистем - первая МоиПодсистемы, и ей подчиненные МоиДобавленныеОбъекты, ОбъектыТиповойИзмененные,ИсправленныеОбъектыТиповойСОшибками.
В первую добавляем свои объекты - удобнее просматривать что добавлено, вторая подсистема позволяет контролировать а не слетели ли доработки, а третья контролировать глюки типовой которые в следующем релизе могут быть исправлены.
(105) Gazza, не согласен. Когда есть список заявок и в комментах писать не вася, а №заявки такой. то потом можно: а) узнать зачем вносились изменения и с какими объектами они связаны; б) проще искать изменения;
//--> I.F. Проведение будущей датой
Процедура ОбработчикИзмененияДаты(Данные)
Если Данные="ДокументОбъект.Дата" ИЛИ Данные="" Тогда
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
//<-- I.F. Проведение будущей датой
//...
////////////////////////////////////////////////////////////////////////////////
// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ
//...
//--> I.F. Проведение будущей датой
ПодключитьОбработчикИзмененияДанных("Дата","ОбработчикИзмененияДаты");
//<-- I.F. Проведение будущей датой
