Поискав интересующую информацию на Инфостарте, пришел к выводу, что, конечно, тема эта поднималась неоднократно, но как-то все решения оставли впечатление незавершенности. Вы можете сказать, что это баян, но это Ваше право.
Итак, имеем некую, например, внешнюю печатную форму, в которой надо выводить автомобиль с дополнительными реквизитами. Справочника «Автомобили» в конфигурации нет (и действительно, зачем он в бухгалтерии сдался?), конфигурация находится на поддержке и ради одного лишнего справочника лишать ее такого статуса неохота.
Вывод напрашивается сам собой: «А пусть пользователь перед печатью ручками вобьет в специальную форму необходимые данные!».
Вывод правильный, и, в принципе, единственный. НО! Если пользователь печатает такую форму раз в год, на этом можно остановиться. А если 50 раз в день? Встает вопрос, где хранить введенные пользователем данные для возможности их использования в дальнейшем.
По большому счету, вменяемых вариантов только два:
1) внешний файл на жестком диске;
2) регистр сведений «Сохраненные настройки».
Первый вариант отметаю сразу, так как, поскольку файл лежит на диске, пользователь вполне может его удалить (неосторожно или умышленно). Плюс ко всему, при переносе базы физически в другое место (в файловом варианте) необходимо позаботится о том, чтобы и с нового места программа «видела» файл. Как по мне, это неудобно.
По поводу второго варианта, Вы можете сказать, что этот регистр предназначен вовсе не для этого, однако, посмотрев на его структуру, видим, что типы измерений и ресурсов — строки, хранилище значения и булево. Так почему бы и нет? Ах да, еще одно измерение — пользователь, для которого сохраняются данные.
По поводу пользователя здесь, на Инфостарте, встречал сетования, что данные сохраняются только для конкретного пользователя. Это не так, можно сохранить и для всех пользователей. Об этом далее.
Итак, в качестве «места дислокации» внешнего справочника выбираем регистр сведений «Сохраненные настройки», который есть практически во всех типовых конфигурациях.
Реализация проста до безобразия:
— создаем таблицу значений с некоторым набором колонок (это описание реквизитов «внешнего» справочника);
— добавляем в таблицу строки (это «элементы» справочника);
— кладем таблицу в структуру и создаем из нее хранилище значения;
— добавляем запись в регистр сведений.
Можно напрямую создать хранилище значения из таблицы, но я предпочитаю структуру, так как кроме самой таблицы в ней можно сохранить и значения других реквизитов обработки.
Далее алгоритм следующий:
— при открытии формы считываем сохраненную структуру
— извлекаем таблицу значений и заполняем табличную часть обработки
— в процессе работы добавляем/удаляем записи из табличной части
— при закрытии выгружаем табличную часть, ложим в структуру и записываем в регистр.
Для того, чтобы все пользователи могли воспользоваться данным «справочником» в измерение регистра «Пользователь» пишем предопределенный элемент справочника «Группы пользователей» — «Все пользователи».
Конечно, не обойтись и без минусов.
Если несколько пользователей одновременно редактируют «внешний» справочник, то запишутся изменения того, кто последний нажал кнопку «Сохранить».
Если в «реквизитах» такого справочника используются значения ссылочного типа (справочники, документы и т.п.), стоит помнить, что при проверке возможности удаления объектов игнорируется факт того, что эти элементы присутствуют в хранилище значения. Соответственно после удаления объектов мы можем получить.
Ну и, конечно, пользователь может банально ручками (неосторожно или умышленно) удалить запись из регистра. Но, как по мне, у записи регистра больше шансов «остаться в живых», чем у файла.
Прилагаемая обработка не несет в себе функциональной нагрузки, а представляет собой лишь пример (шаблон) использования подобного подхода.
PS. Кстати, таким же образом я храню любые настройки внешних обработок, когда не предполагается частое их изменение или индивидуальность (например, Клиент-Банк).
А если далее развить эту тему, то можно в хранилище значения ложить массив структур, каждая из которых описывает «элемент» справочника. Таким образом можно хранить более сложные элементы — с кучей реквизитов и табличных частей. Но это совсем другая история… 🙂
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
В 8.2 есть замечательный механизм — хранилище общих настроек 🙂 Почему бы не использовать его?
Кстати, регистр сведений «Сохраненные настройки» — это прошлый век. Например, в УПП, в БП 2.0 используется справочник «Сохраненные настройки». А в самых новых конфигурациях (УТ 11) — используется как раз таки платформенный механизм — хранилище настроек
Давайте писать грамотно.
hulio ++
(1) hulio, спасибо за идею надо будет заняться этим по подробнее.
Спасибо за статью и донесение идеи в массы.
Если уж извращаться, то мне в голову приходит мысль завести внешнюю БД с нужными справочниками и обращаться к ней, как к внешнему источнику данных 🙂
(7), точно! А обмен данными между ними организовать по e-mail файлами в формате HTML 🙂
Спасибо за статью со многим согласен, кроме регистра и группы пользователей. Считаю, что лучше использовать справочник.
1. Всем пользователям необходим доступ для редактирования? (Ответ: Нет).
2. На большинстве предприятий, с которыми я работаю, за справочник отвечает 1-2 человека, а не все пользователи (в справочнике реализована возможность установить какому пользователю можно енто изменять).
3. справочник это стопроцентно один элемент (естественно если так написан код 😉 дело лично программиста!)
(2) Drak0n, давайте обсуждать публикацию, а не сдавать экзамен по великому и могучему!
Я для себя сделал: в справочнике «Сохраненные настройки» сохраняю значения реквизитов внешних обработок
(4)
просторечие 🙂
(8)
Зря смеётесь, кстати. Делал хранение доп. документов и справочников в отдельной базе, когда «высшие силы» были сильно против снимать конфу с поддержки. Правда, не через HTML, конечно, а через COM… Но, можно и HTML, и XML через WS и ещё как-нить 🙂
А вообще, не вижу суровых минусов хранения настроек во внешних файлах, но спорить не стану — тут каждый выбирает для себя.
Интересны оба варианта, предложенные автором и hulio. За наводку плюс.
(11)
А как же РИБ?
(13)
Не во всех типовых конфах справочник и регистр сведений «Сохранённые настройки» включены в планы обмена. Хранилища настроек — тем более.
Я им говорю: «Не ложьте зеркало в парту!». А они все ложат и ложат, все ложат и ложат.
© «Доживем до понедельника» 🙂
Года два тому назад использовал данную методику для одних клиентов. На практике же удобно только использование во внешних печатных формах. в остальных случаях все равно придется снимать конфигурацию с поддержки… а там уже проще добавлять новые реквизиты и если надо справочники. И такие данные нельзя будет использовать для отчетов.
И еще, почему-то мало кто использует такие вещи как «Дополнительные реквизиты», Данный функционал присутствует в конфигурациях уже давно, но на практике ни где не видел реального применения.
(0) написали бы алгоритмы… читать «родной язык» удобнее, чем линейный текст идеи. а так статья даже очень ничего, полезная 🙂
Очень познавательно, о некоторых методах хранения инфы вообще не задумывался.
Всем спасибо за информативные комментарии!
Автору «+» за «простоНАречие» и идею в общем.
Казалось бы очевидная тема, а нет, есть над чем поразмышлять.
Мне интересно а скорость записи где выше при записи в хранилище или справочник или региср сведений,или вообще в отдельный файл.Впринципе настроек не так много бывает,но все же хотелось бы знать,какой самый быстрый
(20), надо попробовать, но думаю быстрее всего будет в регистр сведений. Если руки дойдут, выложу сюда скрины замеров производительности для всех 4 вариантов.
(1), платформенный механизм «Хранилища настроек» можно использовать, если эти хранилища уже созданы. В «Бухгалтерии для Украины», например ни одного хранилища, как объекта метаданных, нет, а снимать ради своей обработки конфу с поддержки, чтобы «осчастливить» пользователей неохота.
(22) А мой вариант Вам тоже не подойдет7 К сожалению нет конфы «Для Украины»
(23), думаю, доп.реквизиты в данном случае немного не то
полезно.спасибо
Идея не нова, но слабоприменима 🙁
В реальной жизни проще снять с поддержки и получить все плюсы, чем заморачиваться с поддержкой подобного решения.
А в ЗУПе 8.2 нету регистра «Сохраненные настройки», как быть ?
(27) alexmz, зато есть одноименный справочник который выполняет схожие функции…
(16) Василий,
А я давно использую и другим предлагаю:
(16) Василий, можно и такие данные использовать для отчетов — было бы желание. Вытащить таблицу значений из сохраненной настройки, загрузить в СКД и работать с ней как с источником данных. Это вполне можно сделать из внешнего отчета.
(22)
Да, только я говорил про ХранилищеОбщихНастроек. Почувствуйте разницу … И почитайте мануалы 😉
(27) alexmz,
Смотрите (1) — использовать справочник «СохраненныеНастройки» либо платформенный механизм ХранилищеОбщихНастроек
(31) таки да, можно использовать и его, действительно недосмотрел. Спасибо.
(4)
«-» за пункт 2.
Идея интересная, но если требуется хранить большой объем данных, по-моему лучше использовать первый предложенный вариант-сохранение файла на жестком диске, иначе база быстро разрастается и начинает притормаживать.