вывести дополнительный реквизит на форму документа
Расположение дополнительных реквизитов на форме
Продолжаем цикл статей про механизм типовых конфигураций 1С «Дополнительные реквизиты». Чем полезен данный функционал можно почитать во вступлении.
Где найти дополнительные реквизиты на форме
В конфигурации 1С:Документооборот дополнительные реквизиты, добавленные в пользовательском режиме справочнику Внутренние документы по умолчанию, отображаются в форме на закладке «Свойства». Если реквизит носит факультативный характер, то в его расположении на этой закладке нет ничего страшного. Пользователь после заполнение основных реквизитов переходит на вкладку «Свойства» и там вносит дополнительную информацию. А что, если дополнительные реквизиты, назначенные какому-либо виду внутреннего документа, составляют основу для его наполнения. В этом случае желательно чтобы при открытии формы документа они сразу попадали в фокус внимания пользователя. В этом случае расположении реквизитов на закладке, «Свойства» которая «затеряна» среди прочих закладок формы мешает эффективной работе с документом. Напрашивается решение, которое позволит для определённых видов документов при их открытии сразу открывать закладку «Свойства». Это позволит показать пользователю всю основную информацию документа, без необходимости делать переходы по элементам формы.
Добавляем дополнительный реквизит
Допустим мы создали документ с видом «Заявка на прием». В данном документе мы хотим указывать СНИЛС для принимаемого сотрудника. Создаем дополнительный реквизит «СНИЛС».
Делаем привязку этого реквизита к виду документа «Заявка на прием». Создаем новый документ и видим, что на закладке «Свойства» появился наш дополнительный реквизит «СНИЛС».
Все отлично, кроме того, что, как мы говорили выше, кадровику придётся после открытия документа каждый раз переходить на закладку «Свойства» чтобы добраться до нужной информации. Давайте облегчим жизнь пользователям. Сделаем так, чтобы при открытии документа с видом «Заявка на прием», первое что видел пользователь была закладка «Свойства».
Переносим закладку дополнительных реквизитов
Для переноса закладки внесем дополнения в код программы. Для удобства добавим общий модуль, в который будет содержать процедуры и функции для работы с документами. Назовем его маг_РаботаСДокументами. Добавим туда такую процедуру:
Как вывести дополнительные реквизиты на форму списка справочника Графики работы сотрудников. Управляемые формы. Без снятия конфигурации с поддержки
Искала приемлемое решение для идентификации графика работы сотрудников при оформлении кадровых документов, в условиях когда одной позиции штатного расписания могут относиться несколько различных графиков работы.
Я пошла искать подобные темы. Форумчане в голос твердили что без снятия конфигурации с поддержки не обойтись. Вот пример такой темы: https://buh.ru/forum/forum18375/topic80453/
Но на моем проекте жёсткое условие, конфигурацию с поддержки не снимать. Подумав пару часов, нашла решение. Применила дополнительные реквизиты и настройки списка.
Решение:
1. Создаем дополнительный реквизит к справочнику Графики работы сотрудников
Как видно на рисунке выше, дополнительный реквизит самый простой, тип строка.
2. Для удобства переместила доп. реквизит на форме элемента справочника вверх
5. В качестве оформляемого поля выбираем Ссылка
6. Сохраняем настройки. При необходимости, передаем свои настройки другим пользователям. И радуемся обновленному списку справочника
Буду рада если кому-нибудь пригодится такое решение.
Вывод на печать дополнительных реквизитов
(1) Если создали внешнюю печатную форму, неужели не можете вынести дополнительный реквизит?!
Вы когда запрос писали, в нем нужно было либо реквизит указать, либо после обращаться к нему как ссылка.реквизит.
(4) ЕРП не открывал. Но в КА что почти близко. так можно
Область = Макет.ПолучитьОбласть(«Заголовок»);
Область.Параметры.ТвойРеквизит = Твой реквизит;
(1) или так, т.к. например, в БП 3.0 доп.реквизит может быть табличной частью, как у справочников Номеклатура или Контрагенты, а может храниться в регистре сведений.
вот пример:
Заменить на ВЫРАЗИТЬ(ДополнительныеСведения.Объект КАК Справочник.МойОбъект) = &Ссылка
иначе очень много неявных левых соединений. И проблемы с правами доступа.
ну и это почти тоже самое что в модуле УправлениеСвойствами.
Должно выглядеть как то так:
Либо заморачиваться не искать доп.свойство по наименованию, потому что можно получить все свойства объекта, а после из них найти нужное
Вообще для УТ 11.4 вот таким образом работает для любого дополнительного реквизита документа во внешней печатной форме
ЭлементПВХ = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию(«Серийный номер», Истина);
НайденнаяСтрока = СсылкаНаДокумент.ДополнительныеРеквизиты.Найти(ЭлементПВХ, «Свойство»);
Если не НайденнаяСтрока = Неопределено Тогда
Серийный_номер = НайденнаяСтрока.Значение;
КонецЕсли;
ОбластьЗаголовок.Параметры.СерНомер = Серийный_номер;
Заполнение дополнительных реквизитов в модуле на сервере, в правилах КД 2.0, в модуле внешней обработки
Уважаемые коллеги, хотелось бы донести до Вашего сведения небольшой опыт работы по заполнению дополнительных реквизитов Справочников и Документов. Уже много статей посвящено теме этих самых реквизитов, добавлю и свои пять копеек.
В первую очередь хотелось бы заметить, что в самой БСП уже есть ряд процедур и функций которые помогают успешно работать с заполнением дополнительных реквизитов. Главное правильно их использовать. Поэтому и начну я с самого простого варианта.
Предыстория: в одной организации потребовался перенос данных из одной базы в другую одного из справочников. Да вот беда в базе источнике у справочника было два нужных реквизита объекта, а в базе приемнике их не было. Дабы не ломать типовую конфигурацию было принято решение в новой базе создать такое же количество реквизитов, но в качестве дополнительных. Дело оставалось за малым – поместить в эти реквизиты необходимые данные. Благо коды элементов в базе источнике и базе приёмнике были синхронизированы. Самым простым показалось выгрузить связку из трёх реквизитов (Код – Реквизит1 – Реквизит2) в обычный файл формата Excel на стороне источника и загрузить этот файл на стороне приёмника. Опуская момент выгрузки и последующей загрузки файла сразу перейду к моменту, когда файл уже загружен в базе приёмнике в таблицу значений и предстоит все эти данные разложить по нужным элементам справочника, для которого уже заведены два доп.реквизита с именами (для разработчика) «Реквизит1» и «Реквизит2». В общем-то в данном случае всё довольно таки просто. Будем использовать стандартную процедуру БСП.
Обратите внимание, что никаких получений объекта элемента справочника делать не нужно в силу того, что процедура «ЗаписатьСвойстваУОбъекта» сама получает объект и записывает его на сервере. Это удобно, но это и подводный камень о котором будет упомянуто далее.
Предыстория: ситуация аналогичная предыдущей. Только на этот раз для переноса данных было решено использовать не файл Excel, а правила обмена, созданные в КД 2.0. Что для этого потребовалось: два реквизита, которые должны были быть перенесены из источника в приёмник в правилах прописывались как переменные. А уже на стороне приёмника в обработчике события «ПослеЗагрузки» из данных переменных заполнялись доп.реквизиты. И тут мы и натыкаемся на подводный камень процедуры БСП. Если использовать предыдущий алгоритм, то при загрузке данных система выдаст сообщение об ошибке «Ошибка при вызове метода контекста (Записать): Данные были изменены или удалены другим пользователем». Остаётся использовать другой вариант, либо делать разные ухищрения типа правил «повторная загрузка» и передавать данные в несколько этапов. Остановимся на первом варианте.
Пропишем в параметры правил конвертации свойств «Реквизит1» и «Ревизит2» нужные нам значения из источника.
А в обработчике «После загрузки» выполним следующий алгоритм
Далее при записи объекта будет записана и его табличная часть и при открытии элемента справочника в базе Приёмник доп.реквизиты будут на своих местах.
Переходим к ситуации, когда для заполнения дополнительных реквизитов будет использоваться внешняя вставляемая обработка с вариантом использования «Заполнения формы». В данном случае имеется форма документа, из которой и вызывает внешняя обработка заполнения. По своему алгоритму обработка должна получить значения доп.реквизитов Реквизит1 и Реквизит2 и поместить в табличную часть документа «Дополнительные реквизиты». В данном случае при использовании типовой процедуры «УправлениеСвойствами.ЗаписатьСвойстваУОбъекта(…)» создаст те же сложности с различными версиями одного и того же объекта как реквизита формы и находящегося на сервере: после выполнения внешней обработки записать какие-либо ещё изменения реквизитов объекта на форме не представляется возможным. В этом случае потребуется не просто заполнить доп.реквизиты, но и поместить их в тот объект, что находится на сервере. Но это ещё не вся сложность. Дело в том, что дополнительные реквизиты хранятся в объекте как табличная часть, но форме они отображаются именно как реквизиты типа «Поле ввода». По сути дела разработчики заложили в БСП возможность программно создавать набор реквизитов формы по количеству строк заполненных в табличной части «Дополнительные реквизиты» объекта и отображать в них данные из табличной части (те кто занимался этим вопросом наверняка вспомнили реквизиты с длиннющими названиями). Можно конечно пытаться удалить все эти реквизиты и команды с ними связанные (что вполне реально ведь они созданы программно) и вызывать процедуру создания их из процедуры ПриСозданииНаСервере, но есть и более простой вариант. Можно воспользоваться типовой процедурой заполняющей значения реквизитов формы из табличной части объекта УправлениеСвойствами.ЗаполнитьДополнительныеРеквизитыВФорме(…) где в первом параметре передаётся сама форма, а во втором реквизит Объект этой самой формы. Важно отметить, что заполнение на форме этих реквизитов обязательно, так как если они останутся пустыми, что при закрытии формы с записью в доп.реквизиты запишутся эти самые пустые значения.
В процедуре внешней обработки заполнения требуется прописать следующий алгоритм:
Примечательно, что процедура «ЗаполнитьДополнительныеРеквизитыВФорме(…)» можно так же использовать и в том случае если доп.реквизиты заполняются по кнопочке из формы.
На этом завершаю рассмотрение программного заполнения доп.реквизитов и надеюсь, это поможет кому-то ускорить процесс разработки.
Дополнительные реквизиты в типовом отчете и их отсутствие
Когда это может понадобиться?
Допустим, нам необходимо добавить справочнику дополнительный реквизит и вывести его в типовой отчет.
Затем заполняем несколько партнеров для наглядности и переходим к отчету «Сводная ведомость расчетов». Я быстренько убрал лишнее и добавил поле «Дата сверки».
И вот у нас уже есть первый блин.
Ладно. Форматирование, чтобы убрать время, добавить не сложно, а вот как вытащить реквизит в отдельное поле, не очевидно.
Теперь нам нужен отбор по партнерам, у которых Дата сверки не заполнена. Добавляем «Дата сверки» «Не заполнено». Отбор работает.
Усложняем. Добавляем реквизит типа булево «Есть откат». Вытаскиваем в отчет… Все также.
ЕстьNull(Партнер.[Есть откат (Общие)], Ложь)
Скорее всего в вашем случае можно сразу в пользовательском поле написать ЕСТЬNULL, но в моем случае система решила партнеров переименовать в Клиентов.
П.С. И добавить формат поля Есть откат «БЛ = »; БИ = ‘V'» для красоты.
Описанный пример, конечно, фантазия и в реальной практике не встретится. Но если кто-то не знал и кому-то пригодится, значит я писал не зря. Спасибо, что дочитали до конца.