Можно ли в 1с предприятии создать общий реквизит
Реквизиты формы обеспечивают ее связь с данными. При этом один (и только один) из реквизитов может быть назначен основным; он не обязательно может быть того типа данных, к объекту которого мы рисуем форму. Но от типа данных основного реквизита будет зависеть поведение формы. Кроме изменения поведения формы, происходит изменение контекста модуля формы. Наряду с методами и свойствами формы, в нем становятся доступны методы и свойства объекта, являющегося значением основного реквизита. Важно, что формы типа "Произвольная форма" не имеют основного реквизита. В этом случае поведение формы определяется только настройками пользователя. Рассмотрим вопросы по основным реквизитам.
- Определяет источник данных для формы в целом
- Определяет стандартные возможности платформы для работы формы с данными типа, заданного у основного реквизита
- Для обеспечения возможности программного обращения к реквизитам объекта из локального контекста формы
- Обеспечивает визуализацию реквизитов объекта на диалоге формы
- Верны 2 и 3
- Верны 1 и 2
- Для описания состава данных, которые отображаются, редактируются или хранятся в форме
- Для отображения и редактирования данных в форме
- Верны 1 и 2
Вопрос 10.07 экзамена 1С:Профессионал по платформе. Что бы произвольной управляемой форме назначить основной реквизит.
- форму нужно сделать основной, основной реквизит при этом определяется автоматически
- нужно в свойствах реквизита формы установить флажок "Основной реквизит"
- нужно войти в меню "Правка", пункт "Основной реквизит" и выбрать нужное значение
- нужно заполнить свойство "Данные" формы, выбрав нужный реквизит формы
Вопрос 10.08 экзамена 1С:Профессионал по платформе. Что бы произвольной обычной форме назначить основной реквизит.
- форму нужно сделать основной, основной реквизит при этом определяется автоматически
- нужно в свойствах реквизита формы установить флажок "Основной реквизит"
- нужно войти в меню "Правка", пункт "Основной реквизит" и выбрать нужное значение
- нужно заполнить свойство "Данные" формы, выбрав нужный реквизит формы
Вопрос 10.09 экзамена 1С:Профессионал по платформе. При наличии одного основного реквизита формы можно ли добавить еще один основной реквизит?
- Это не возможно
- Можно посредством назначения соответствующего значения свойства реквизита формы
- Можно только программно, при обращении к объекту "Форма"
- Можно посредством добавления еще одного значения к соответствующему свойству формы
Правильный ответ первый, основной реквизит строго один, т.к. связь с объектом должна быть однозначна.
Вопрос 10.113 экзамена 1С:Профессионал по платформе. Какой из реквизитов формы, представленной на рисунке, является основным?
Потребовалось объединять данные двух независимых баз в одной. Решение лежащее на поверхности - использование общего реквизита в режиме "Разделять" и использование разделяемых данных "Независимо и совместно". Для создания базы использовалась "Библиотека стандартных подсистем", где уже присутствовал общий реквизит рекомендованного 1С типа "Число". К чему это привело будет ниже.
Механизм общих реквизитов расписывать не буду, т.к. это сделано неоднократно. Просто напомню, что при включении в состав общего реквизита какого-либо объекта в его таблице на сервере добавляется поле.
Итак, общий реквизит "ОбластьДанных" автоматически распространялся на все объекты метаданных.
Добавил свой реквизит "ИсточникДанных" - тип СправочникСсылка (о рекомендациях 1С на тот момент не знал), в файловой базе доделал всё, что надо, проверил, работает "замечательно" (почему в кавычках напишу в самом низу). Перенес в рабочую серверную базу и оказалось, что при установке параметров сеанса все разделенные данные "пропадают".
Оказалось, при наличии двух общих реквизитов у объекта в его таблице на сервере добавляется вычисляемое поле " _DataSeparationHash" формула:
где [_Fld164] - это общий реквизит "ОбластьДанных" типа число(7,0)
а [_Fld2260RRef] - это мой общий реквизит.
Устанавливаем параметры сеанса (только мой общий реквизит, "ОбластьДанных" не используем), выполняем запрос "Первые 333" к справочнику без условий, который должен вернуть 333 строки, но запрос оказывается пустым. На сервере видим:
Итак, платформой, несмотря на отключенное использование разделения по реквизиту "ОбластьДанных", накладывается условие по полю " _Fld164" , впрочем, это никак не влияет, проблема оказалась в условии по полю " _DataSeparationHash" CAST(SUBSTRING(HASHBYTES('MD5',CONVERT(VARCHAR, 0.0 )),1,4) AS INT) ^ CHECKSUM(?))
, тогда как в формуле
CONVERT([int],substring(hashbytes('MD5',CONVERT([varchar],[_Fld164], 0 )),(1),(4)),0)^checksum([_Fld2260RRef])
Решение - не использовать два общих реквизита у одного объекта.
З.Ы.
Возможно, если использовать общие реквизиты нерекомендованного 1С типа, т.е. не число, то такой "косяк" и не всплывет.
И коротко про документы и их движения (досконально не разбирался, но в объяснение "замечательно" в кавычках).
Включил в состав общего реквизита три документа и один регистр накопления, по которому эти документы делают движения.
В файловой базе можно было "задвоить" движения, сначала провести при выключенном разделении, потом при установленном разделителе.
в серверном варианте возникает ошибка вставки неуникального индекса.
Так что, если пришли к необходимости использования общего реквизита, то придется распроводить документы, устанавливать разделитель и проводить. Или напрямую обновлять таблицы регистров (хотя сам я не решился на такое).
Предисловие
Начиная с версии платформы 8.2.14.x и до последних актуальных релизов, в дереве метаданных конфигурации имеется такой объект как "Общие реквизиты". Подобный функционал предоставляла еще платформа 7.7, но в восьмой ветке эти возможности стали доступны далеко не сразу.
Сегодня мы рассмотрим нюансы использования данного объекта при разработке конфигураций, а также проанализируем структуру его хранения на стороне базы данных.
Возможности
В типовых конфигурациях можно заметить, что для многих документов создан реквизит "Комментарий". Конечно, разработчику не составило труда вручную добавить его в каждый документ в конфигураторе, но теперь у нас есть более быстрый вариант проделать эту операцию.
Рассмотрим пример. В некоторой тестовой конфигурации, которой на самом деле не существует :), создадим четыре документа с именами "Doc1", "Doc2", "Doc3" и "Doc4". В каждый из документов нам необходимо добавить комментарий, причем он должен отображаться в форме списка каждого из документов.
Для этого создадим новый объект конфигурации в ветке "Общие -> Общие реквизиты" и назовем его "Комментарий". Тип значения укажем "Строка" длинной 255 символов. Также включим многострочный режим. Результат описанных действий Вы можете видеть на скриншоте "Настройки общего реквизита" ниже.
Все настройки аналогичны настройкам любого реквизита документа, за исключением раздела "Использование". Здесь нас интересует опция "Состав", в которой определяется состав объектов конфигурации. Именно здесь и будет определяться список тех объектов, для которых будет использоваться этот общий реквизит. Включим использование для первых трех документов.
Отметим, что режим использования "Автоматически" ориентируется на настройку "Автоиспользование" общего реквизита. В нашем примере свойство "Автоиспользование" для реквизита установлено в "Не использовать". Значит для документа "Doc4" общий реквизит не будет задействован, пока не включить использование явно.
В режиме конфигуратора сделаны все необходимые настройки. Запустим режим предприятия и откроем форму списка "Doc1". Мы увидим, что реквизит доступен как в списке, так и в форме документа.
То есть появился новый реквизит "Комментарий", имеющий строковой тип и многострочный режим редактирования. Такую же картину мы будем наблюдать для документов "Doc2" и "Doc3".
Для общих реквизитов доступны стандартные возможности отбора, а в режиме конфигуратора работа с ними в форме документа никак не отличается от работы с обычными реквизитами.
Например, если создать запрос к документу "Doc3", то в доступных полях будет общий реквизит "Комментарий".
Единственное, чем функционал общего реквизита отличается от обычного, так это отсутствием возможности добавить его в графу журнала документов. В остальном же с ними можно работать стандартным образом.
Что там внутри
Для ответа на этот вопрос проанализируем как платформа 1С работает с общими реквизитами на стороне базы данных, а также каким образом к ним строятся запросы на выборку данных.
Сразу скажу, что для хранения значений общих реквизитов не используется отдельная таблица в базе данных. Если бы это было так, то использование данного объекта конфигураций отрицательно сказалось на общей производительности системы, так как запросы к реквизитам документа усложнились за счет использования дополнительного соединений. Общие реквизиты сохраняются в дополнительной колонке, добавляемой для таблиц документов, включенных в их состав. То есть также, как если бы реквизит был добавлен непосредственно в самом объекте.
Обратимся к документу "Doc4", который не был включен в общий реквизит "Комментарий". Чтобы показать, как изменяется таблица документа в SQL-базе при добавлении его в состав общего реквизита, обратимся к следующему скриншоту.
Был добавлен общий реквизит с типом "Булево", в состав которого мы включили документ "Doc4". В итоге, при обновлении структуры информационной базы, в исходную таблицу "_Document10" было добавлено поле "_Fld17" булевого типа. Отсюда следует, что общие реквизиты добавляют к таблицам БД как дополнительные поля, аналогично тому, если бы мы создали вручную реквизиты для каждого документа.
Соответственно, запросы к таблицам SQL-базы будут в точности повторять запросы к полям, если бы они были созданы обычным способом. Делаем вывод, что явное отрицательное влияние на производительность отсутствует.
Но все ли так
Как обычно, не все так идеально. У общих реквизитов есть один существенный минус, как и у любого универсального подхода - это отсутствие возможности гибкой настройки этого реквизита для отдельных таблиц. На то он и общий, не так ли?
Например, в той же конфигурации, включив индексирование для общего реквизита "Комментарий", этот индекс будет создан в таблице каждого документа. Даже если индекс для конкретного документа будет не нужен, то отключить его средствами платформы 1С не будет возможности. Вот так индекс был добавлен в 3 документа, в которые мы добавляли общий реквизит "Комментарий".
Платформа 1С добавила индексы по общему реквизиту во все таблицы, которые входят в его состав.
Вроде бы все хорошо, но иногда отсутствие возможности управлять гибкой настройкой индексов создает проблемы.
Зачем отключать этот индекс? Обычно индексы добавляются для конкретных ситуаций. Добавляя их заранее для всех объектов, скорее всего некоторые из них будут избыточными (не всегда конечно же). С использованием общего реквизита Вы просто не сможете отключать индекс там, где он не используется.
Если сильно захотеть, то индекс удалить все же можно, воспользовавшись этим подходом, ведь где индекс можно добавить своими скриптами, такими же скриптами его можно и удалить. Там же в статье описаны все плюсы и минусы такого способа.
Кроме настройки индексирования Вы также лишаетесь возможности делать другие точечные настройки общего реквизита для объектов:
- Использование в полнотекстовом поиске
- Историю данных
- Заполнение из данных заполнения
- Проверку заполнения
- И др.
Таким образом, использование общего реквизита обосновано, если все перечисленные проблемы не относятся к поставленной задаче разработки.
А как обстоят дела с использованием этого механизма в типовых конфигурациях?
В типовых конфигурациях
В типовых решениях Вы не часто встретите использование общих реквизитов, за одним большим исключением - это разделение данных из подсистемы "Работа в модели сервиса" из БСП. Подсистема позволяет разделить все хранимые данные в базе на изолированные части, чтобы в одной базе данных могли работать несколько компаний. Все это было сделано для облачной работы решений на платформе 1С.
По моему мнению, общие реквизиты как раз и были изначально созданы разработчиками платформы, чтобы реализовать разделение данных в конфигурациях. Но это, конечно, не точно :)
При работе в модели сервиса в конфигурации должен быть включен механизм разделения данных, который позволяет разделить все хранимые данные, а также работу прикладного решения на отдельные части.
Разделение данных можно найти во всех популярных решениях. На стороне базы данных они также отражены дополнительным полем, но за важным отличием - это поле добавляется во все индексы объекта с разделением на первую позицию. Не важно, используйте Вы разделение данных или нет - разделитель у Вас есть в базе и платформа использует его для построения запросов. В 100% случаев это числовое поле. Если разделение данных не включено, то оно заполняется значением "0" и по этому же значению устанавливается фильтр во всех запросах.
Есть интересный момент в анализе планов запросов при наличии разделителя в индекса. Как известно, операция "Table scan" или "Index scan" (сканирование, просмотр таблицы / индекса) обычно не очень хороший признак выполняемых запросов на больших таблицах. Взгляните на такой случай.
Уже из текста можно понять, что запрос скорее всего написан с ошибкой, т.к. выбирать всю таблицу реализаций - это последнее дело на больших базах. Если в базе разделителей нет (например, если у Вас старая и добрая УТ 10.3), то план запроса будет с операцией сканирования индекса.
Запрос платформой 1С будет сгенерирован примерно такой:
- Логическая операция: Table scan
- Количество прочитанных строк: 6076 (всего в таблице 6076, то есть она была прочитана полностью)
- Очень неоптимально. Но какой запрос - такой и план.
Теперь выполним примерно такой же запрос на "Бухгалтерии предприятия 3.0", где разделитель данных уже присутствует. И вот результат.
SQL-запрос уже получил дополнительный фильтр по разделителю.
План тоже претерпел изменения.
От предыдущего примера план отличается тем, что операция теперь "Index Seek", вместо "Table Scan". Хотя прочитанных строк и затраченных ресурсов на выполнение запроса практически не изменилось.
Что все это значит? А то, что не нужно смотреть в плане запроса на выполняемые операции и ожидать, что если выполняется "Index Seek" (Поиск в индексе), то значит с запросом все хорошо. Поиск в индексе бывает разный, и не всегда оптимальный. Рекомендую отличную статью по работе с планами запросов "Планы запросов - это просто!" от Андрея Овсянкина.
Еще одним моментом, связанным с разделением данных, является падение производительности для тех пользователей, которые могут работать со всеми областями данных. В этом случае платформа 1С не ставит явный отбор по разделителю и практически все запросы превращаются в сканирование таблиц и индексов. Подробнее об этом Вы можете прочитать в статье "Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS" от Евгении Карук.
А Вы использовали когда-либо разделение данных? Есть чем дополнить материал?
Жизнь обычного разработчика
В самом начале статьи Вы видели пример добавления общего реквизита, но он не имеет ничего общего с практическими задачами. За весь опыт работы с платформой и различными конфигурациями мне известны лишь несколько кейсов, когда разработчики их применяли:
- Добавление реквизита для объекта в типовой конфигурации, чтобы не затрагивать основной объект. Вроде как сделано, чтобы обновлять конфигурацию было проще.
- Создание общих атрибутов для объектов в виде общих реквизитов (даты создания и изменения, ответственный и другие произвольные атрибуты).
- Просто бездумное добавление полей, чтобы меньше "кликать" в конфигурации.
В отраслевых решениях можно встретить различного рода общие реквизиты, в отличии от решений фирмы "1С".
Использовать?
Все зависит от конкретной ситуации. Если в один прекрасный момент Вам понадобиться создать для всех документов конфигурации один и тот же реквизит с одинаковыми свойствами, то использования общего реквизита поможет сэкономить Вам время. Есть моменты, которые могут помешать использовать его возможности - это невозможность его использования в графе журнала документов и отсутствие гибкой настройки для каждого документа отдельно в дереве метаданных. Думаю, что в следующих версиях платформы станет возможным использовать общие реквизиты в журналах документов, но кто знает.
В завершении скажу, что за все время работы с платформой 1С:Предприятие 8.x, мне не приходилось использовать общие реквизиты для решения практических задач. В типовых конфигурациях, с которыми имел дело, также не находил их применения, за исключением редких отраслевых конфигураций. Поэтому 100 раз подумайте, прежде чем добавлять их в конфигурацию.
Общий реквизит в 1С 8.3 — это объект метаданных платформы, позволяющий использовать один реквизит для многих объектов конфигурации (справочников, документов, планов счетов и т.д). Объект создан в основном для облегчения труда разработчика и разделения данных.
Общие реквизиты были первоначально реализованы в версии 1С 7.7, но сразу в платформу 8 версии разработчики его не включили. Механизм общих реквизитов был введен разработчиками 1С только в релизе 8.2.14.
После добавления общего реквизита его можно использовать и в запросах и выводить на форму объектов — внешне он ничем не отличается от обычного реквизита.
Единственное ограничение общих реквизитов — невозможность использования их в журнале документов.
Настройки и свойства общего реквизита в 1С
Рассмотрим основные настройки и свойства общих реквизитов, отличные от других объектов конфигурации:
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Состав — список объектов, к которым будет использован общий реквизит, настройка напоминает настройку плана обмена.
Автоиспользование — настройка определяет, будет ли использоваться общий реквизит для тех объектов, у которых в составе указан режим использования «Автоматический».
Разделение данных — эту настройку рассмотрим отдельно.
Разделение данных в 1С с помощью общего реквизита
Разделение данных — механизм, аналогичный механизму ограничений прав на уровне записи (RLS). Однако производительность данного механизма более эффективна, и он настраивается проще.
Механизм позволяет настроить отображение только элементов, которые может видеть пользователь. К примеру, можно разграничить все объекты (документы, справочники и т.д.), где установлена определенная организация.
Настройка разделения данных с помощью общих реквизитов 1С
Для настройки в общем реквизите необходимо указать разделение данных — Разделять. Сразу после нажатия система предложит создать параметры учета по умолчанию:
При этом необходимо будет при старте системы указать параметры сеанса, как это сделать, с примером было описано в статье Параметры сеанса 1С.
На этом настройка окончена — пользователю будет доступна только та информация, которая указана в выбранных параметрах сеанса.
Пример использования общего реквизита
Разберем настройку общего реквизита в 1С 8.3 на примере каркасной конфигурации и реквизита Организация:
В системе имеется 3 документа, где необходимо указание реквизита Организация: это Приходная Накладная, Расходная Накладная, Начисление Зарплаты.
- Создаем новый Общий реквизит, указываем тип — СправочникСсылка.Организация.
- В составе расставляем для наших документов — Использовать.
Все, настройка окончена!
Система отображает общий реквизит «как свой»: и в запросах, и в реквизитах формы, и в других местах. Вот такое волшебство! 🙂
Не добавляется общий реквизит 1С 8.3
Вы можете столкнуться с данной проблемой — кнопка Добавить не активна:
Связано с тем, что у вас установлен не тот режим совместимости конфигурации. Для этого снимите режим совместимости «Версия 8.2.13» в палитре свойств конфигурации:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Справочники 1С — специализированный объект древа метаданных, который служит для хранения статичной информации справочного характера. Например, в типовых конфигурациях можно увидеть следующие виды: Контрагенты, Номенклатура, Сотрудники, Основные средства и т.д. Информация в справочниках, как правило, часто не изменяется. Справочники в дальнейшем используются практически во всех объектах учета как разрез учета или справочная информация.
Справочники в конфигураторе 1С 8
Ниже мы рассмотрим настройку и проектирование справочника из конфигуратора на примере справочника «Номенклатура».
Вкладка «Основные»
На вкладке «Основные» указывается имя, синоним, представление объектов, описание назначения.
Вкладка «Иерархия справочника»
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Здесь устанавливается иерархичность справочника.
Иерархия в 1С 8.3 бывает двух типов — «групп и элементов» и «элементов«. Отличается тем, что в первом случае родителем (папкой) может быть только папка (группа), а во втором случае родителем может быть и элемент.
«Размещать группы сверху» — флаг отвечает за отображение групп в форме списка.
Также в настройках можно ограничить количество групп иерархии справочника соответствующей настройкой.
Вкладка «Владельцы»
Справочник может быть подчинен другому справочнику. С точки зрения конфигурирования 1С 8.3 это значит, что у подчиненного элемента становится обязательным реквизит «Владелец». Пример такой связи справочников в типовых конфигурациях «Номенклатура — Единицы Измерения», «Контрагенты-Договоры Контрагентов».
Владельцем справочника могут также быть следующие объекты метаданных: планы обмена, планы видов характеристик, планы счетов, планы видов расчета.
Вкладка «Данные»
Самая важная вкладка с точки зрения программиста. На ней указываются реквизиты справочника.
У справочника есть набор стандартных реквизитов, которые не редактируются программистом 1С 8.2, список их можно увидеть, нажав кнопку «Стандартные реквизиты»:
Остановлюсь на каждом подробнее:
- ЭтоГруппа — реквизит с типом булево, показывающий, группа это или элемент. Доступен только в иерархическом справочнике. Обратите внимание, значение этого реквизита невозможно изменить в режиме 1С: Предприятие.
- Код — реквизит, тип число или строка (как правило строка). Номер, присваиваемый системой автоматически. Как правило, рассчитывается как (предыдущий код + 1). Рекомендую использовать именно строковый тип, потому как сортировка числовых значений происходит не так, как нужно. Можно использовать как представление справочника в списке и в полях ввода. Как правило, используется для поиска элемента при вводе по строке. Если Вам нужно убрать поле Код, укажите в длине строки ноль.
- Наименование — реквизит, обязательный к заполнению, строкового типа. Максимальная длина строки — 150 символов. Можно использовать как представление справочника в списке и в полях ввода. Как правило, используется для поиска элемента при вводе по строке. Если Вам нужно убрать поле Наименование, укажите в длине строки ноль.
- Родитель — реквизит, имеющий тип СправочникСсылка.. Доступен только в иерархическом справочнике. Указывает на вышестоящего родителя в иерархии. Если Элемент или Группа находятся в корне справочника, указывается значение Справочник..ПустаяСсылка.
- Владелец — ссылка на элемент-владелец текущего элемента (группы) справочника. Доступен только в подчиненном справочнике 1С.
- ПометкаУдаления — реквизит с типом булево. Отвечает за отображение «пометки удаления» в системе. Помеченный на удаление элемент считается непригодным к использованию, однако на нём могут оставаться старые движения в документах.
- Ссылка — поле строкового типа. В этом реквизите хранится уникальный идентификатор объекта — GUID. То, что в системе мы видим в визуальном отображении под название «ссылка», — это всего лишь представление объекта. Невозможно изменить.
- Предопределенный — тип булево, отображает, является ли элемент предопределенным, об этом позже. Невозможно изменить.
На вкладке «Данные» так же указывается представление справочника в системе, до версии 8.2.16 представление могло быть лишь Кодом или Наименованием. В свежих версиях платформы (начиная с 8.3) представление можно описать самостоятельно в модуле менеджера с помощью обработчика «ОбработкаПолученияПредставления».
Вкладка «Нумерация»
Серия кодов — определяет, как нумеровать справочник, можно ввести нумерацию справочника в разрезе владельца. Например, у контрагента «Рога и копыта» будет иметься своя нумерация договоров — «1, 2, 3» и тд.
Вкладка «Формы»
Тут описываются формы для справочника. Если конфигурация запускается как в обычном, так и управляемом режиме, тогда вкладок с формами по умолчанию будет две: «основные» и «дополнительные» — для обычного и управляемого приложения разные.
На этой странице есть немаловажное свойство справочника — «Ввод по строке«. Это очень удобная функция 1С 8, позволяющая при заполнении данных в поле ввода не заходить в справочник, а набрать его наименование, код или т.п. и выбрать из выпадающего списка нужный элемент. Выглядит это так:
Вкладка «Прочее»
На вкладке можно получить быстрый доступ к основным модулям справочника — модулю объекта и модулю менеджера.
На странице можно также определить список предопределенных элементов справочника. Это элементы, которые невозможно удалить в режиме Предприятия. К предопределенным элементам можно обратиться в конфигураторе напрямую, по имени, например: Справочники.Номенклатура.Услуга.
На этой вкладке также определяется режим блокировки — автоматический или управляемый. Использование полнотекстового поиска, а также справочная информация о справочнике, доступная в режиме 1С: Предприятия.
Минивидео, как работать со справочниками:
Читайте также: