Доработки в 1с как сделать
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С» нужен большой развёрнутый ответ. Если коротко — доработки помогают улучшить систему и получить преимущество по сравнению с другими компаниями.
Вариантов доработок много: есть более «стойкие», есть менее, есть хорошая практика доработок, есть плохая. Попробуем разобраться в плюсах и минусах различных вариантов, а также попробуем понять, почему они перестают работать и как снизить вероятность появления ошибок.
Сделать доработку так, чтобы она гарантированно не слетала после обновлений — невозможно.
-
Доработки 1С могут быть такими:
- Внешние доработки: печатные формы. отчеты и т.д.
- Расширения
- Изменения кода типовой конфигурации
Внешние доработки: внешние обработки, отчеты и т.д.
1С — сильная система, в которой многие процессы автоматизированы, но часто пользователи просят доработать программы чуть-чуть, по мелочи:
- разработать специфические отчёты, которых не хватает
- доработать или написать новые печатные формы с нужной информацией и оформлением
При этом обновление самой конфигурации при наличии таких доработок — простейший процесс, который можно сделать даже без участия человека.
Почему могут не работать после обновлений?
Такой способ доработки — один из самых стабильных. Проблемы появляются, если разработчики типовой конфигурации, которую мы и обновляем, что-то поменяли в своих механизмах. Но то, что может поломать внешние доработки, меняется не часто.
Как избежать ошибок?
Способ есть один и он универсальный для каждого варианта доработки системы. И он довольно простой — после обновлений нужно просто проверить каждую доработку. Как бы это ни звучало просто, возникает много нюансов и вопросов.
Когда возникают проблемы?
По сути, внешние доработки это множество мелких доработок, отдельных программных модулей.
Проверить код каждой доработки даже минимальным встроенным синтаксическим контролем, который проверяет самый минимум, огромная задача. Нужно открыть каждую разработку и запустить синтаксический контроль. Таких доработок может быть много, а проблемы возникают не часто.
Получается дилемма: либо открывать каждую разработку и проверять синтаксическим контролем и работой в пользовательском режиме, тратить на это много времени и, как правило, денег заказчика, либо ничего не проверять.
Что на самом деле делает программист при обновлении?
Обычно, программисты выбирают вариант ничего не проверять. Этот вариант и является оптимальным. Ошибки исправляются по обращениям пользователей (да, получается, что тестируют конечные пользователи). Но искать ошибку не надо, она уже найдена, обычно довольно понятна и может быть быстро исправлена.
Как снизить затраты на поддержку доработок?
Как раз для снижения затрат обычно и выбирается вариант — делать все без проверки. Если реально все проверять каждое обновление (и делать его раз в месяц), то затраты получатся большими, а проблемы встречаются нечасто.
Как повысить стабильность доработок?
Все внешние разработки поделить на критичные и некритичные. Критичные обычно влияют на оперативную работу компании. Например, если при ошибке в доработке остановится выписка документов, это повлияет на финансовые результаты компании.
Для проверки таких критичных доработок можно выделить опытного пользователя, который будет тестировать всё. Ещё один вариант — договориться об этом с вашей обслуживающей компанией.
Расширения: новое слово в доработках 1С
Расширения позволяют точечно дорабатывать 1С: делать заплатки в отдельных документах, добавлять нужные кнопки или писать целые подсистемы — новые функциональные блоки у программы. Доработки выполняются менее «инвазивным» способом и позволяют контролировать изменения основной конфигурации. Если изменение произойдет, разработчику будет выдано соответствующее предупреждение.
Многие пользователи, которые знакомы со значительными доработками 1С (особенно с горьким опытом предыдущих систем), знают понятие «конфигурация должна быть на замке». Это значит, что доработки выполняются внешними модулями, а ваша конфигурация останется нетронутой. С этой точки зрения расширения похожи на внешние доработки из прошлого пункта.
Расширения появились достаточно давно, но не все программисты их используют. Мы советуем присмотреться к этому механизму: он прост в использовании, не меняет основную конфигурацию 1С и помогает быстро добавлять нужные функции.
Почему могут не работать после обновлений?
Причина все та же (она будет всегда одинаковой) — код вашей конфигурации поменяли разработчики типовой конфигурации 1С, а доработки на него опирались, поэтому перестали работать.
Как избежать ошибок?
Конечно, тут опять же нужно все проверять после каждого обновления. Но сделать это уже труднее. Расширения позволяют поменять много разных мест в программе, и сразу далеко не очевидно, где именно и что проверять.
Когда возникают проблемы?
В двух основных ситуациях:
доработки в расширениях сделаны неправильно (про это позже)
у вас установлено много расширений
Можно создать стандарты доработки расширений, мы работаем именно так. Стандарты помогают сократить частоту поломок после обновлений, но не избежать их на 100%.
А если устанавливать множество расширений, один и тот же участок программы может быть доработан в разных расширениях. Тогда расширения могут конфликтовать друг с другом, превращая доработки в сложнозапутанный клубок. Например, одну и ту же печатную форму доработали разными расширениями. Доработки конфликтуют, и после обновления форма не работает.
Решение в этой ситуации - уменьшить количество расширений. Это облегчит и поддержку, и развитие.
Что на самом деле делает программист при обновлении?
Сама 1С обновляется легко, она же «на замке».
После обновления обязательно проверяется совместимость расширений с текущей версией программы.
Получается, не нужно проверять множество разных доработанных внешних программных модулей, а можно проверить всё в одном месте.
Спасает ли это на 100%? Нет, без «пользовательского тестирования» все равно не обойтись. Несмотря на то, что грамотно написанные расширения гораздо стабильнее, чем исправление внутри самой конфигурации, и много проблем позволяют выявить в автоматическом режиме.
Как снизить затраты на поддержку доработок?
Для сокращения издержек разработчик и в этом варианте не проверяет «пользовательскую» работоспособность. Иначе поддержка выходит опять же слишком дорогой.
Исправляются проблемы автоматической проверки совместимости, а остальное — по обращениям пользователей.
Как повысить стабильность доработок?
В первую очередь нужно, чтобы разработчики создавали расширения по стандартам и грамотно их использовали.
Если простой для вашей компании критичен, а в программах 1С много расширений, можно обновлять не рабочую базу, а её копию. После обновления копии ваш пользователь или подрядчик тестируют критичный функционал. Если всё в порядке, обновляете рабочую базу с обновлёнными расширениями.
Изменения кода типовой конфигурации
Доработка самой конфигурации — серьёзный шаг. Чтобы её дорабатывать, нужно понимать, зачем, почему и какие сложности будут с обновлениями. Обновляет доработанную конфигурацию программист. При этом важно отслеживать все изменения и не затереть код прошлых изменений.
Именно при доработанной конфигурации сложнее всего обновлять программы, и это вызывает страх у пользователей.
Важно отличать случаи, когда действительно нужно дорабатывать конфигурацию, а когда можно обойтись внешними доработками или расширениями. Обычно менять конфигурацию не нужно в случаях с печатными формами, кнопками.
Например, у вас есть документ Счёт на оплату. В него нужно добавить кнопку «Дать скидку до минимальной наценки». Для решения этой задачи не надо менять конфигурацию, достаточно написать внешнее расширение.
Если изменить типовую конфигурацию там, где можно этого не делать, плюсов от внешних доработок не будет. Но гарантированно будет головная боль от обновлений.
Существует и «полностью добавленный функционал» — отдельно стоящие подсистемы, которые не опираются на типовой код конфигурации и обновление его практически не затрагивает. Но все же большинство доработок обычно касаются именно функционала типовой конфигурации.
Почему могут перестать работать после обновлений?
Причина одна: что-то поменялось в конфигурации поставщика. И последствия тут могут быть сложнее, чем в случае с внешними доработками.
Если в каких-то местах ваш программист изменил код, то изменения от разработчиков 1С могут войти в конфликт с этими изменениями. В этом случае изменения вашего программиста стираются — код заменяется на типовой. Поэтому программисту, который обновляет доработанные конфигурации, нужно вручную отследить изменения и перенести их в новую конфигурацию. При этом важно не потерять изменение: человеческий фактор влияет максимально.
Хорошая практика — комментировать любое именение типового кода, описывать места изменений. Но и это спасает не всегда.
Как избежать ошибок?
Главное — не менять конфигурацию, если доработку можно сделать без этого. Если без изменений никак не обойтись, и это подтверждает грамотный программист, нужно доработать программу аккуратно, добавить пометки об изменении кода прямо в нём.
В таких случаях проверить все изменения и как они влияют на вашу программу проблематично. Даже если сравнить построчно типовую программу и вашу, доработанную, нужно долго разбираться что и зачем было изменено.
Как обычно, избежать поломки может только тотальная проверка всех мест, которые гипотетически могут поломаться, но их может быть очень много. И нужно потратить крайне много сил на исправление и подготовку теста.
Когда возникают проблемы?
В общем случае всегда. Практически любое изменение стандартного кода влечет повышенную сложность сопровождения вашей 1С. Дальше все зависит от квалификации и внимательности программистов, которые вносят изменения в программу и (в большей степени) обновляют её.
Что на самом деле делает программист при обновлении?
-
Основная задача программиста при обновлении такой 1С — постараться не потерять изменения:
- отметить места, которые слетели
- вручную перенести затертый код
- проверить, не выдает ли программа ошибку при запуске
А если разработчики внесли много изменений в типовую конфигурацию, или вы долго не обновляли свою базу, сложность всех этих процедур усложняется многократно.
Обычно на все эти процедуры уходит много сил и внимания разработчика, и о глобальной проверке «пользовательской работоспособности» уже никто не думает: она может занять намного больше времени, чем само обновление.
Как снизить затраты на поддержку доработок?
Избегать доработок внутреннего кода в тех случаях, когда это делать не надо, этим часто грешат начинающие программисты.
Если пришлось дорабатывать «по живому», то опять же самый простой и дешевый сценарий — это давать обновленную базу пользователям и в случае ошибок стараться оперативно исправлять. Однако частота возникновения ошибок уже довольно существенная.
Как повысить стабильность доработок?
-
Тут много направлений:
- Работать над качеством разработки и комментирования кода.
- Если доработки ведутся несколькими программистами, налаживать коммуникацию и правила доработок.
- Вести документацию по обновлениям, фиксировать места, которые точно нужно проверить после обновления.
- Обязательно обновлять вначале копию, а потом уже рабочую базу.
- Составить чек-лист проверок критичного функционала и договориться, кто его будет проверять. В идеале нужно на копии базы подготовить примеры (тест-кейсы) по которым кто-то будет обязательно проходить и только после теста разрешать обновлять рабочую базу.
- Следить, чтобы тест-кейсы были не просто составлены, но и полностью проверялись. Если пользователи не проверяют обновлённую копию или просто делают там пару кликов, проверка не сработает.
Подытожим
- Дорабатывать 1С можно тремя основными способами: внешними доработками, расширениями и изменениями типовой конфигурации.
- Важно выбирать способ доработки исходя из целей, сложности поддержки и затрат.
- Нужно стараться использовать расширения, они не меняют типовую конфигурацию и создают меньше сложностей при обновлении.
- Разработчики проверяют работоспособность кода, синтаксические ошибки в нём. Но программисты не отратабатывают пользовательские сценарии.
- «Проверить, чтобы все работало», к сожалению, невозможно и нецелесообразно, но можно составить чек-лист критических проверок.
- Сама проверка функционала в «пользовательском режиме» — очень непростая задача, затратная, иногда, кажется, что бессмысленная: если проверяем уже 3-е обновление подряд, ничего не ломается, а времени тратится много.
- Нужно писать тест-кейсы, по которым реально проверить работу критического функционала.
- Важно следить, чтобы ответственные пользователи проверяли критический функционал: это снижает количество ошибок в дальнейшем.
А что делать, если хочешь дорабатывать 1С и испытывать меньше головной боли?
Автоматическое тестирование — инструмент, кторый помогает дорабатывать 1С. Автоматическое тестирование позволяет с одной стороны получать новые нужные функции, а с другой — не сталкиваться с постоянной поломкой критического функционала на рабочей базе.
Это сложный способ, но он помогает держать систему в рабочем состоянии и избегать простоя в важной работе. О том как это все устроено, и какие есть плюсы и минусы, разберемся в следующей статье.
Автотесты мы используем на собственных разработках и планируем внедрять автоматические тесты клиентам, чтобы повысить качество сопровождения программ 1С.
Как проводится доработка
1С достаточно гибкая система, и в ней имеются настройки для существенного изменения типового решения. Настройку рекомендуют делать непосредственно после установки ПО. Это помогает избежать ненужных растрат и проблем с эксплуатацией. Однако допустимо изменение конфигурации до нового уровня и в процессе её использования.
Стадии настройки 1С
- Установление и первоначальное заполнение 1С из коробки с настройкой баз данных, установкой системы безопасности и ключей.
- Пополнение классификаторов — списки контрагентов, валютные курсы, единицы измерения и пр. Автоматизация загрузки с серверов.
- Адаптация к учёту на основании особенностей в работе организации — настройка обмена данными между базами.
- Обучение пользователей.
- Перенос данных из прежней системы.
- Заведение пользователей, назначение и настройка прав.
- Введение в эксплуатацию.
Если первичная настройка не помогла подстроить функционал под Клиента, помогает доработка до нового уровня с привлечением программистов 1С. Она проводится в соответствии с составленным техническим заданием. Техзадание помогает заказчику определиться в ходе его составления с тем, что он хочет получить. Для доработчика техзадание выступает чётким перечнем задач, которые нужно исполнить. Если задачи непростые, прибегают к технологии проектного внедрения. Последняя включает исследование бизнес-процессов, написание технического задания, разработку внешних и глубинных доработок, тестирование и доработку внедрения 1С, установку модификаций, обучение пользователей.
Доработка должна быть правильной с объективной оценкой уровня необходимого внедрения в систему. По возможности нужно избегать внесения в систему серьёзных изменений. Несмотря на заложенный в программах потенциал по их изменению, доработчик должен понимать уровень своей ответственности. За глубокой доработкой идут определённые последствия по дальнейшему использованию и обновлению программы. Новый функционал может не удовлетворить пользователя из-за появления иных сложностей в работе с программой. Поэтому нужно объективно оценивать профессионализм посторонних доработчиков и обращаться за помощью к проверенным или рекомендованным компаниям. Если соблюдать рекомендации разработки, то при адекватных трудозатратах уже на проектной стадии получится обеспечить экономию на дальнейшей поддержке и на обновлении. Самостоятельные действия часто приводят к обратному эффекту. К тому же новый функционал потребует поддержки в будущем. Разовое взаимодействие с программистами на тему доработки возможно исключительно при небольших изменениях в системе.
Когда актуальна доработка программ 1С
Во все продукты на платформе 1С включён неплохой функционал возможностей. Будь то «Управление торговлей», «Бухгалтерия» и иные программные продукты. Но, если вы не находите в типовом решении ответы на все ваши вопросы и нужного функционала, рождается потребность в доработке. Основные цели доработки 1С — это доведение автоматизации процессов до желанного уровня, увеличение удобства работы в программе, внедрение нового функционала. Часто изменения касаются только части интерфейса, но бывают и серьёзные правки при внедрении какого-то нового алгоритма и подсистем. Это зависит от потребностей предприятия для поддержки должного уровня бизнеса или его продвижения на рынке.
Перечень ситуаций, когда доработка конфигурации становится актуальной
- Необходимо внедрить аналитические инструменты, в том числе в виде дополнительных форм отчётов (например, добавление нового внешнего отчёта без потери конфигурационной поддержки, доработка уже встроенных отчётов).
- Требуется изменить интерфейс, подстроив его под нужды пользователей.
- Необходимо осуществить разовый перенос данных в другую базу или из другой базы (1С или сторонние базы).
- Необходимо организовать постоянный обмен со сторонней базой данных — настройка интеграции с другими базами 1С, интернет-площадками, со сторонними программами (в том числе с разработкой нетиповых обменов и подключением оборудования).
- Необходимо ускорить работу программы и исключить зависание системы с замером её производительности, устранением ошибок в результате технических сбоев, отключением неиспользуемых модулей.
- Требуется усилить безопасность данных внутри системы и с учётом политики безопасности компании (организовать разграниченный доступ между старыми пользователями и с добавлением нового).
- Необходимо перенастроить документооборот и формы документов под нужды организации с доработкой встроенных печатных форм, добавлением печатей и логотипов, формированием печатных форм посредством 1С, MS Word и т. д.
Изменения в программном коде это тоже доработка, но более серьёзного уровня. Здесь можно поделить уровень внесения изменений в программу — внешнее изменение и внутреннее. Перечисленные в пунктах изменения являются внешними. Корректировка кода относится к внутреннему изменению программы.
Также обращение к доработчикам актуально при совершенствовании баз в облачном сервисе, при оптимизации оборудования, архивировании и восстановлении баз 1С, восстановлении доступа к ним, ручном обновлении конфигураций (в том числе доработанных ранее), апгрейде до нового уровня конфигурации (ПРОФ/КОРП).
Если в процессе работы сотрудником выполняются какие-то нестандартные ситуации, также можно рассмотреть возможность усовершенствования системы по ним. Таким образом, функционал системы поддаётся значительной корректировке. Главное условие доработки в этом случае — сделать работу так, чтобы система подвергалась дальнейшему обновлению. После таких изменений программа начинает называться нетиповой.
Что нужно освоить для доработки программы
Перед тем как прорабатывать конфигурацию, нужно приобрести базовые навыки по работе с программным обеспечением. Для этого надо обратиться к документированию и конфигурированию.
Документирование
Все привносимые в программу изменения должны быть зафиксированы. Документация в такой ситуации дополняет имеющуюся в хранилище или другой контрольной системе информацию. Документация при этом пишется программистом не ради самой документации. Это должна быть осознанная работа для облегчения процесса доработки и использования нового вида программы в дальнейшем.
При документировании специалисты минимизируют количество ошибок, которые потенциально могут возникнуть в процессе обновления конфигурации поставщиком.
Конфигурирование
Сделать универсальную коробочную разработку, готовую к работе для всех без исключения компаний, это непосильная задача. Поэтому 1С предоставляет пользователям возможность самостоятельного конфигурирования.
Самостоятельное конфигурирование позволяет улучшить систему и настроить её под собственные потребности. Но доработчикам и программистам рекомендуется предельно внимательно изучать рабочий функционал. Проблему можно обходить с минимальным ущербом для системы, находя альтернативные решения. Влезать глубоко в типовые механизмы нужно в исключительных случаях, когда безуспешно опробованы лояльные варианты внесения изменений. Множество задач можно эффективно решить и без применения опций конфигуратора.
Например, когда у пользователя наблюдается нехватка документальных и справочных полей, он может активировать дополнительные реквизиты в настройках и добавить их. Такие реквизиты не меняют конфигурацию и вполне годятся для использования.
Иной пример — формирование печатных форм. Для этого можно использовать механизм, предоставляемый в БСП, либо прописать код в модуле формы. Но надо понимать, поддержка и обновление программы усложнится. Поэтому нужно объективно оценивать необходимость внесения корректировок в конфигурацию.
Рекомендации и приёмы доработки
Доработка не должна выполняться поспешно или с совершением ошибок при оформлении кода, так как это приводит к проблемам при поддержке и обновлении системы. Поэтому лучше следовать простым рекомендациям для проведения доработки. В целом задача доработчика в этом случае состоит во внесении необходимых изменений, но при минимальном нарушении типовой конфигурации. Небольшие лайфхаки упрощают процесс взаимодействия с системой в будущем.
Перечень рекомендаций для оптимального модернизирования программы
Этот перечень рекомендаций не обязателен к применению в полном объёме. Отсюда можно взять и отдельные фишки. Они помогают внедрять изменения не столь разрушительно. То есть нивелируют ущерб и упрощают дальнейшую работу с системой. Не все программисты способны достойно сделать доработку установленной типовой конфигурации (или уже доработанной ранее). Принципиальной необходимости обращения к сторонним специалистам нет при наличии с установившей программу фирмой договора на обслуживание — договора информационно-технологического сопровождения.
Что ещё может облегчить процесс доработки: самоопределение тестовых баз, обработка инициализации, вставка элементов в справочник предопределённых значений, просматривание временно созданных табличек в отладчике.
Внесение изменений в код основных модулей это радикальный метод. Применять его лучше в крайних случаях. Избежать такой доработки можно через расширения. Благодаря им доработчики вносят изменения в специально предназначенную структуру данных. Проблема состоит в том, что целый перечень задач невозможно исполнить через расширения. Также доступна доработка типовых программ внешними отчётами и обработками. Изменения здесь тоже вносятся лояльно с сохранением прежнего уровня поддержки программного продукта.
Напоследок
Доработка программы 1С даёт повышение уровня информационной безопасности и удобства пользования программой. Благодаря этому растёт эффективность работы отдельных пользователей и целых подразделений. Этому способствует расширенный функционал программы, внедрение более точных отчётов и т. д. Управление рабочими процессами совершенствуется, а бизнес в целом развивается намного стремительней и выходит на лидирующие позиции в рыночной плоскости.
Важные моменты доработки
- Применение надёжных решений, которые можно хорошо реализовать только при привлечении профессионалов с опытом в этом направлении.
- Возможность изменения широкого профиля опций.
- Оперативность — удовлетворение поставленных задач в оптимальные сроки.
- Гарантия качества на услуги.
Учтите, что обновление доработанных программных продуктов это более сложный и финансово более затратный процесс. Если типовая разработка и обновляется благодаря типовым средствам, то для доработанной версии требуется особый подход. В противном случае можно просто потерять все доработки.
Настройка фоновых заданий и простая корректировка форм документов под силу даже обычному пользователю. Однако, несмотря на наличие в свободном доступе подробных инструкций по доработке, мы не рекомендуем заниматься этим самостоятельно. Расширение или иное изменение типовых решений может быть сделано хорошо исключительно профессионалами.
Наша компания готова адаптировать программное обеспечение под любые бизнес-требования на основании частных клиентских нужд. Обращайтесь только за профессиональной доработкой системы установленного у вас программного обеспечения и получайте уникальный продукт. С нашими услугами и их стоимостью вы можете ознакомиться по ссылке.
Сегодня мы рассмотрим одну из самых частых задач, с которой сталкиваются специалисты по 1С – доработку отчета типовой конфигурации.
О чем эта статья
В статье рассмотрен пример доработки типового отчета «Расчетный листок» в конфигурации «Зарплату и Управление Персоналом 3.0». На данном примере показываются общие шаги разработчика, в случае если он слабо знаком с конкретной реализацией конкретного типового отчета на базе СКД.
Применимость
В материалах статьи в качестве примера используется конфигурация, «Зарплата и Управление Персоналом», редакции 3 3.0.25.122. Но от этого примеры доработки, продемонстрированные в видео, не стали устаревшими, т.к. акцент сделал именно на логике рассуждений разработчика перед которым поставлена подобного рода задача. Смело смотрите видео, это must have!
В качестве конфигурации выбрали “Зарплату и Управление Персоналом 3.0” – в силу следующих причин:
- Отчеты из ЗУП традиционно считаются сложными
- Иногда даже задача – понять, откуда берутся данные в отчет – вызывает у специалистов сложности.
Что конкретно мы будем делать
Это реальная задача из Мастер-группы – доработаем отчет “Расчетный листок” так, чтобы в шапке выводилась информация о дате приема сотрудника на работу.
Очень простая задача :)
Но есть одна сложность – информацию о дате приема типовой отчет не содержит, её нужно получать с помощью отдельного запроса.
И запрос этот нужно интегрировать в типовой отчет…
А параллельно мы разберем и приемы работы с СКД:
- Анализ программного кода типового отчета – определение точек минимального воздействия на конфигурацию
- Использование расширения языка запросов для системы компоновки данных – выражения в фигурных скобках
- Программное формирование отчета на СКД – доработку процедуры ПриКомпоновкеРезультата
- Вывод результата компоновки в коллекцию – дерево значений
- Доработку текста запроса типового отчета – получение связанной информации
- Работу с настройками компоновки – определение структуры, использование нескольких группировочных полей в одной группировке
- Использование макета – табличного документа при выводе отчета на СКД
- Отладку типового отчета, запущенного в фоновом режиме
Итак, поехали! 21 минута видео :)
Видео 1: Как за 10 минут понять логику формирования типового отчета
В этом уроке приступаем к решению задачи по модификации Расчетного листка в ЗУП 3.0.
Суть задачи состоит в том, чтобы вывести в отчет связанную информацию из других объектов – необходимо запросом получать дополнительные данные.
Но прежде, чем писать код, нужно найти точки минимального воздействия – чтобы внести в конфигурацию как можно меньше изменений.
В данном уроке мы показываем, как понять логику формирования типового отчета на СКД с программным заполнением полей и ручным выводом данных в табличный документ.
Видео 2: Как с помощью 2 строк кода изменить заполнение отчета
В уроке показано, как найти, где хранятся требуемые пользователю данные – это могут быть различные объекты системы. В этой задаче очень помогает умение читать объемные запросы.
В итоге задача решается с минимальными изменениями:
- Новая строка в макете
- Левое соединение в запросе
- Две строки в программном коде.
Также из видео Вы узнаете, для чего в запросе может использоваться конструкция “Выбрать Первые 0”.
Эта тема детально раскрыта в курсе:
Поддержка – 2 месяца. Объем курса – 34 учебных часа.
Не откладывайте свое обучение!
Комментарии / обсуждение (65):
Добрый день! Вопрос по УТ 11. В типовых отчётах добавляются доп. реквизиты. Вопрос: как их исключить из отчетов?
Подробнее.
Существует, примерно, 100 видов номенклатуры, к каждому из которых привязан свой набор доп. реквизитов от 5 до 10).
При изменении варианта отчета, где используется номенклатура, при раскрытии её, вываливается список всех доп. реквизитов. Жуткий тормоз. Можно ли сделать так, чтобы при отборе или добавлении поля, не выводились эти доп. реквизиты?
Добрый день!
Нет, поскольку это платформенный механизм – для справочника Номенклатура в конфигураторе настроены характеристики на уровне объектов метаданных. Поэтому они будут добавляться в список полей номенклатуры при работе с отчетами, динамическими списками, т.е. в механизмах, базирующихся на системе компоновки данных.
Рассмотрите вариант переноса доп. реквизитов в обычные реквизиты справочника Номенклатура. Это должно увеличить производительность описанных действий.
Раньше, помнится, надо было настраивать в СКД на закладке “Характеристики”, а сейчас, выходит, на Табл. часть “Доп. реквизиты” программист повлиять не может?
В УТ 11 не требуется заполнять закладку Характеристики в тексте запроса набора данных.
Дело в том, что в этой конфигурации настроены характеристики на уровне объектов метаданных. Например, можно в конфигураторе обратиться к справочнику Номенклатура, в контекстном меню выбрать пункт Характеристики:
Здесь указано, откуда система будет получать перечень характеристик и их значения.
СКД учитывает эту настройку, поэтому дополнительно прописывать характеристики в запросе не нужно.
По поводу переноса в обычне реквизиты. Дело в том, что у каждого вида номенклатуры свои доп. реквизиты и они не пересекаются. Это сколько же их будет?!
Можно на копии базы сделать тестовый пример, проверить производительность и все остальные аспекты, принять решение, стоит ли выполнять такие действия на рабочей базе.
Добрый день! Прошу помощи подскажите пожалуйста?
Клиент попросил доработать типовой отчет в БП 3.0 , конфигурация на поддержке. Было принято решение сделать отчет внешним, но столкнулся с проблемой…
Сохраняю отчет как внешний и пытаюсь открыть его через файл открыть и тут же выдается ошибка “не известный тип объекта метаданных, ВнешнийОтчет.ЗадолженностьПокупателейПоСрокамДолга”. Как победить эту ошибку? В УТ 11.4 таких проблем не возникало.
Добрый день!
Причина ошибки заключается в том, что у внешнего отчета или обработки в принципе нет модуля менеджера. А у отчета или обработки из конфигурации такой модуль присутствует.
В БП в модуле менеджера отчетов есть программный код, а в УТ – нет. Этим объясняется разница в поведении конфигураций.
При сохранении отчета или обработки во внешний файл модуль менеджера будет потерян. Поэтому нужно учесть этот момент, доработать внешний отчет, например, добавив нужные процедуры в модуль объекта.
Альтернативный вариант – создать расширение, в котором реализовать новый отчет, модуль менеджера в таком случае будет доступен.
>> Также из видео Вы узнаете, для чего в запросе может использоваться конструкция “Выбрать Первые 0”
А я так и не понял для чего используется такая конструкция?
Ведь на выходе такой запрос будет возвращать пустую таблицу с колонками.
А как тогда выбираются данные для этой таблицы?
Добрый день!
Этот текст запроса программно при компоновке отчета будет заменен на сложный запрос, который действительно извлекает данные из базы, а нем уже не будет конструкции ВЫБРАТЬ ПЕРВЫЕ 0.
Текст такого запроса формируется программно из отдельных кусочков, временных таблиц, зависит от различных условий, поэтому указать его непосредственно в отчете не получится.
Но в то же самое время нужно определить, какие поля набора данных должны быть в отчете. Для этого создается фиктивный текст запроса в наборе данных отчета. Он не будет выполняться, единственная его задача – описать поля отчета, а также типы данных этих полей.
Благодарю за ответ.
То, что это не запрос, а его “набросок” – это понятно.
Но не понятно назначение конструкции “ВЫБРАТЬ ПЕРВЫЕ 0”. Ведь если ее убрать (заменить на “ВЫБРАТЬ”), то ничего не изменится, т.к. этот запрос все равно не исполняется, а модифицируется из кода.
Да, конечно, не изменится. Но можно выделить 2 способа использования именно такой конструкции:
1. Она обеспечивает формирование пустого результата запроса с набором колонок нужного типа. Если использовать просто ВЫБРАТЬ, то в результате будут данные (одна строка с пустыми значениями).
2. Это может быть удобным маркером, признаком, что именно этот запрос нужно подменить. Потому что в обычном запросе для получения данных из базы такая конструкция точно не будет применяться.
Да. Действительно. Для получения пустой таблицы, указанного пользователем формата – весьма интересный прием.
Благодарю за ответы.
Пожалуйста. Обращайтесь:)
И приходите к нам на курс по СКД. В Мастер-группе отвечаем на Ваши вопросы по СКД.
Процедура Печать(ТабДок, Ссылка) Экспорт
// Макет = Документы.РасчетСтипендии.ПолучитьМакет(“Печать”);
Запрос = Новый Запрос;
Запрос.Текст =
“ВЫБРАТЬ
| РасчетСтипендии.Дата КАК Дата,
| РасчетСтипендии.Номер КАК Номер,
| РасчетСтипендииСтуденты.Студент КАК Студент,
| РасчетСтипендииСтуденты.Группа КАК Группа,
| РасчетСтипендииСтуденты.ТипСтипендии КАК ТипСтипендии,
| РасчетСтипендииСтуденты.НомерСеместра КАК НомерСеместра
|ИЗ
| Документ.РасчетСтипендии.Студенты КАК РасчетСтипендииСтуденты
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.РасчетСтипендии КАК РасчетСтипендии
| ПО РасчетСтипендииСтуденты.Ссылка = РасчетСтипендии.Ссылка
|ГДЕ
| РасчетСтипендии.Ссылка В(&Ссылка)
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| РасчетСтипендииРезультатыСдачи.НомерСтроки КАК НомерСтроки,
| РасчетСтипендииРезультатыСдачи.Предмет КАК Предмет,
| РасчетСтипендииРезультатыСдачи.РезультатСдачи КАК РезультатСдачи,
| РасчетСтипендииРезультатыСдачи.Студент КАК Студент
|ИЗ
| Документ.РасчетСтипендии.РезультатыСдачи КАК РасчетСтипендииРезультатыСдачи
|ГДЕ
| РасчетСтипендииРезультатыСдачи.Ссылка В(&Ссылка)”;
РезультатЗапроса = Запрос.ВыполнитьПакет();
Выборка = РезультатЗапроса[0].Выбрать();
ОбластьЗаголовок = Макет.ПолучитьОбласть(“Заголовок”);
ОбластьИнформацияСтудента = Макет.ПолучитьОбласть(“ИнформацияСтудента”);
ОбластьРезультат = Макет.ПолучитьОбласть(“Результат”);
ОбластьРезультатыСдачиШапка = Макет.ПолучитьОбласть(“РезультатыСдачиШапка”);
ОбластьРезультатыСдачи = Макет.ПолучитьОбласть(“РезультатыСдачи”);
ОбластьЗаголовок.Параметры.Заполнить(Выборка);
ОбластьЗаголовок.Параметры.Дата = Формат(Выборка.Дата, “ДФ=dd.MM.yyyy”);
ТабДок.Вывести(ОбластьЗаголовок);
//ТабДок.Вывести(ОбластьРезультаты);
ОбластьИнформацияСтудента.Параметры.Заполнить(Выборка);
ТабДок.Вывести(ОбластьИнформацияСтудента, Выборка.Уровень());
ТабДок.Вывести(ОбластьРезультат);
ТабДок.Вывести(ОбластьРезультатыСдачиШапка);
//Выборка = Выборка.РезультатыСдачи.Выбрать();
//Каждому студенту свои предметы
Выборка2.Следующий();
ОбластьРезультатыСдачи.Параметры.Заполнить(Выборка2);
ТабДок.Вывести(ОбластьРезультатыСдачи, Выборка2.Уровень());
Смотрите в Конфигуратор – есть. Видимость, доступность – все Ok.
Тем не менее – на форме новые реквизиты не видно, хотя они есть!
Добавили (заимствовали) форму Заказа в расширение. Вывели на заимствованную форму добавленные в расширении реквизиты. Все хорошо…
Выходит новый релиз конфигурации поставщика, где у документа добавлен КакойТоНовыйРеквизит, который выведен на форму документа в конфигурации поставщика.
Если после обновления расширение успешно подключится, то, как минимум, в режиме Предприятия на форме документа не будет этого нового реквизита.
И с этим надо что-то делать:)
На самом деле нет повода для паники :) Нужно просто помнить, как 1С “вычисляет”, что показывать на форме.
Дело в том, что платформа использует сразу 3 формы:
- Форму из основной конфигурации
- Сохраненную форму
- Форму из расширения.
И как они взаимодействуют – мы разберем в новом видео.
12 минут видео, 100% полезности :)
Профессиональная доработка 1С не должна вызывать проблем с обновлениями
Мы подготовили новый курс, который рассказывает не только про расширения, но и про другие инструменты для доработки типовых конфигураций.
- Как дорабатывать типовые конфигурации внешними средствами
- Как разрабатывать и использовать расширения
- Оптимальные приемы обновления
- Все, что экономит, страхует, помогает.
Musthave для внедренцев.
Комментарии / обсуждение (74):
Добрый день!
Добавил в расширение РегистрБухгалтерии в БП 3.
При обновлении на релиз 3.0.106. все перестало работать.
При анализе таблиц регистра обнаружил добавленные поля ValueDt1…
,которые отсутствовали в старой конфигурации. Каким образом уровнять структуру моего регистра в расширении с типовой конфигурацией? Если создать новое расширение и в нем новый регистр, то все поля создаются. При попытке объединить, создать регистр в старом расширении, все добавленные поля исчезают. Не могу найти решение неделю. Что делать?
Добрый день!
В этом релизе Бухгалтерии изменился режим совместимости конфигурации на Версия 8.3.16. Возможно, в этом причина. Попробуйте изменить режим совместимости расширения.
Добрый день!
Это я сделал сразу. Результат не изменился.
Спасибо за информацию про сохраненную форму, но
что делать, если в основной конфигурации нет формы, а в расширении добавляю реквизит, создаю форму элемента (пример, справочник производители в конфигурации УТ11.4) в итоге при открытии формы – открывается “почти типовая форма” с типовыми реквизитами, но декоративные элементы (типа надписи или группы) появляются.
При попытке обратиться к созданному в расширении элементу система выдает ошибку, будто нет такого реквизита (обращался к нему из формы расширения, в правом окне с реквизитами он был, на форме элемент тоже присутствует, но при запуске 1С они все исчезают)
Добрый день!
Предполагаю, что дело в правах доступа к добавленному реквизиту. Если у пользователя нет прав на просмотр реквизита, то на форме в пользовательском режиме он не отобразится.
Добрый день!
А можно в расширении для формы выбора переопределить ПараметрыВыбора.
Например изменить параметры выбора для формы выбора договора: “Отбор.ВидДоговора((СПоставщиком, СКомиссионеромНаЗакупку, СФакторинговойКомпанией))” ?
Извиняюсь, пока писал сам разобрался.
Алексей, хорошо – бывает :)
Добрый день!
Спасибо.
Хорошая новость, потому что пути к данным действительно слетают, это мешает использовать расширения на практике.
Добрый день!
1-3. Да, такое поведение воспроизводится и на платформе 8.3.16.
Можно вот такой способ обхода использовать. В редакторе формы в расширении добавить новый элемент (Ins с клавиатуры или нажать кнопку Добавить), выбрать его тип – Таблица, затем в свойстве ПутьКДанным указать Объект.ИмяТабличнойЧасти.
После этого система запросит, нужно ли добавить колонки. На командной панели будут отображаться кнопки, а в списке событий – будут доступны все события, в том числе и ПриАктивизацииСтроки.
4. Тоже встречается такое. По наблюдениям – что-то происходит со свойством ПутьКДанным. Если его перевыбрать у проблемных элементов, они снова начинают отображаться. Еще иногда помогает закрыть конфигуратор, снова открыть, нажать кнопку Обновить расширение формы. Точной закономерности пока не уловил.
Добавил форму документа в расширение. На форме есть дерево значений, добавляю новую колонку но система почему то не дает изменить ни название ни тип колонки.
Подскажите пожалуйста, что нужно сделать, чтобы система дала изменить название и тип колонки?
Так что попробуйте платформу посвежее использовать.
ААААААААААААААААААААААААААААААААА.
О боги… я раз пять то удаляла форму из расширения, то снова добавляла. 1С:Предприятие 8.3 (8.3.14.1854). И все таки мой реквизит ТЧ документа там появился…
Спасибо за статью и видео – без них я бы не справилась.
Пожалуйста!
Интересного обучения!
Добрый день! Подскажите, а почему нельзя удалить реквизит (колонка реквизита формы “тфПараметрыНазначения” с типом ТаблицаЗначений, которое было заимствовано из основной конфигурации), который я добавила в расширение.
Правильно ли я сделала, когда удалила сам реквизит “тфПараметрыНазначения” и добавила его в расширение обратно?
Добрый день!
Тут все зависит от версии платформы. Если версия младше 8.3.14, то удалить колонку таблицы значений можно, иначе – нет. Это связано с тем, что в платформе 8.3.14 изменился механизм работы с формами – при заимствовании формы происходит заимствование только элементов формы (реквизиты, команды и параметры формы не заимствуются). Можно предложить вариант поработать со свойством видимости колонки на форме и при этом ее не удалять из таблицы значений.
Ольга, спасибо за ответ. Да, платформа 8.3.15.
Мне этот реквизит совсем не нужен (реализовала задачу по другому), и добавляла я только его одного, поэтому вариант, который я написала (удалила сам реквизит “тфПараметрыНазначения” и добавила его в расширение обратно) мне подошёл. Проверила работу в данной форме, вроде ничего не поломалось.
Конечно, если бы я добавила много реквизитов, а потом захотела бы удалить один, то получается при таком подходе (удалении реквизита и добавлении его обратно) пришлось бы остальные добавленные мной реквизиты обратно добавлять, что не удобно, но всё таки правильней, а вариант с видимостью на мой взгляд не очень корректный, так как вызывает в последующем непонимание зачем был добавлен данный реквизит и наверно затрачивает дополнительный объем памяти.
Спасибо ещё раз за ответ, теперь буду думать дважды когда буду добавлять свои реквизиты на форму в расширении. Надеюсь, правда, разработчики продумают этот момент.
Здравствуйте!
8.3.14.1779, ЕРП 2.4.8.84
Такая проблема – есть расширения, в которых не активна кнопка “добавить в расширение”.
В чём может быть проблема?
Добрый день!
У меня не воспроизвелось. Возможно, зависит от типа объекта, который Вы пытаетесь добавить в расширение. Или проблема конкретного релиза платформы.
А как дружит расширение с конвертацией данных? Если я создал расширение, добавил в нём новый реквизит в документ, а потом выгрузил информацию о структуре информационной базы – попадёт туда расширение?
Добрый день!
В тестовую конфигурацию загрузил расширение, в котором в документе добавил реквизит.
При помощи обработки MD82Exp.epf из Конвертации данных выгружаю структуру конфигурации в xml-файл. В полученном файле новый реквизит из расширения присутствует.
А что если ситуация интереснее?! Вы только добавили реквизиты в только что созданную форму расширения и они не показываются. В чем дело если сохраненная форма не причем?
Добрый день!
Возможно, дело в правах доступа.
Здравствуйте. Платформа 8.3.14, Добавил в расширение заимствованный объект “ПодразделенияОрганизаций”, добавил в него свой реквизит “GC_Кластер”. Заимстовал форму элемента, пытаюсь вывести на форму добавленный реквизит, но в реквизитах объекта на форме его попросту нет. Раньше вроде бы таких проблем не было, сейчас как то иначе это делается?
Добрый день!
В конструкторе формы добавляю Объект в расширение:
После этого на форму можно вынести созданный в расширении реквизит:
Добрый день. Спасибо за ответ. После того как добавляешь объект в расширение, с формы сразу же пропадают реквизиты, которые не добавлены заимствованием в расширение. И в режиме предприятия форма выглядит после этого ровно так как в расширении, без половины реквизитов. Научите добавлять скрины сюда
2. На этой странице нельзя добавлять скриншоты, только на страницах Мастер-группы.
Недопонимание.
1. Создаю новое расширение (единственное)
2. В расширение добавляю заимствованием справочник “Подразделения организаций”, объект и форму объекта
3. Захожу в расширении в объект “Подразделения организаций” и добавляю в него 2 реквизита – Реквизит1, Реквизит2
4. Захожу в расширении в форму объекта, нажимаю правой кнопкой мыши по корню “Объект”, жму добавить в расширение (без этого нет возможности вывести на форму добавленные мной реквизиты, см. пункт 3). После данного действия, элементов на заимствованной форме становится раза в 2 меньше чем было до.
Как мне кажется с формы исчезают элементы, которые не были добавлены заимствованием в расширение. Например есть в реквизитах формы набор записей регистра сведений (типовой реквизит), а сам регистр сведений в расширение я не добавлял. При выполнении вот этого действия (нажимаю правой кнопкой мыши по корню “Объект”, жму добавить в расширение) данный реквизит пропадает с формы в расширении.
Если в расширении в форме объекта нажать правой кнопкой по корню “Объект” и нажать удалить, а затем обновить форму расширения из конфигурации, реквизит снова появляется на форме.
5. Если мои догадки и пункта 4 верны, то получается не очень весело, например на форме есть 50 типовых реквизитов, которые ссылаются на разные справочники, регистры сведений, измерения регистров сведений, нужно пройтись по конфигурации и руками подобавлять каждый такой объект в расширение.
Конфигурация Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.10.50), платформа 8.3.14.1565
Посидел немного поковырялся еще
1. Создаю новое расширение (единственное)
2. В расширение добавляю заимствованием справочник “Подразделения организаций”, объект и форму объекта
3. Захожу в расширении в объект “Подразделения организаций” и добавляю в него 2 реквизита – Реквизит1, Реквизит2
4. Захожу в расширении в форму объекта, нажимаю правой кнопкой мыши по корню “Объект”, жму добавить в расширение (без этого нет возможности вывести на форму добавленные мной реквизиты, см. пункт 3). После данного действия, элементов на заимствованной форме становится раза в 2 меньше чем было до.
Я не имею ввиду данные формы, сами поля остаются, но у них почему то слетает путь к данным, который раньше был “Объект.ИмяТиповогоРеквизита”, как следствие реквизиты перестают отображаться на форме для пользователя. При этом, если руками прописать путь к данным, то слетает синоним реквизита, который был в основной конфигурации.
Например имя реквизита – “ПроцентСевернойНадбавки”, синоним – “% северной надбавки”, нажимаю правой кнопкой мыши по корню “Объект”, жму добавить в расширение, путь к данным слетает, прописываю руками путь к данным, реквизит вновь отображается на форме, но с синонимом “ПроцентСевернойНадбавки”
Читайте также: