Всем доброго дня.

Нужен совет достаточно продвинутых прогеров. Недавно столкнулся с одной обработкой (внешней обработкой) написанной для ЕРП/УТ/КА (версия релиза не важна).

В общем, в программном коде этой обработки вводятся такие понятия, как виртуальные объекты.

```1c
    // *** Префиксы в именах процедур и функций.
    //
    // * ВО... - виртуальные объекты (виртуальные справочники и документы). Виртуальные объекты - это имитация существования в конфигурации
    // справочников и документов, на самом деле отсутствующих в конфигурации.
    // Примеры виртуальных объектов:
    // - Справочники: "_РезультатыПосещений", "_ШаблоныАнкет";
    // - Документы: "_Мерчендайзинг", "_Посещение".
    // * ВДок... - виртуальные документы (см. описание "ВО...")
    // * ВСпр... - виртуальные справочники (см. описание "ВО...")
```

Обработка работает так: есть форма списка документов, а есть форма непосредственно самого документа (Правильнее будет сказать - обычная форма внешней обработки). Объект формы (в обоих случаях) - это естественно (ВнешняяОбработка.ИмяОбработки.). В этом плане никаких непонятностей нету. Когда надо сохранить документ (например, командой "Провести и закрыть" на форме внешней обработки) система сохраняет объект формы в хранилище системных настроек (дополнительно перетаскивает туда ГУИД формы для уникальности записи) вот таким незатейливым кодом:

```1c
    // Сохранение виртуального объекта в хранилище значений (и самого объекта и обновление таблицы виртуальных объектов данного вида).
    // Параметры:
    // СтррВО - Структура - системные свойства виртуального объекта (результат вызова функции ВОСвойстваОбъекта()).
    // GUID - УникальныйИдентификатор - идентификатор объекта.
    // СтррОбъект - Структура - сохраняемый виртуальный объект.
    //
    Процедура ВОЭлементСохранить(СтррВО, GUID, СтррОбъект) Экспорт

    // Этап 1. Сохранение самого элемента в хранилище.
    СохранитьОбъектВХранилище(СтррВО.Префикс, GUID, СтррОбъект);

    // Этап 2. Обновление в хранилище ТЗ списка элементов
    ТЗн = ВОТЗЗагрузить(СтррВО, Истина);

    СтрокаТ = ТЗн.Найти(GUID, "ID");
    Если СтрокаТ = Неопределено Тогда
    СтрокаТ = ТЗн.Добавить();
    СтрокаТ.ID = GUID;
    КонецЕсли;

    ЗаполнитьЗначенияСвойств(СтрокаТ, СтррОбъект);

    ВОТЗСохранить(СтррВО, ТЗн);

    КонецПроцедуры

    // Процедура сохраняет заполненную структуру объекта в хранилище.
    // Параметры:
    // Префикс - Строка - префикс, используемый в качестве имени значения из хранилища.
    // UUID - УникальныйИдентификатор - идентификатор объекта.
    // СтррОбъект - Структура - сохраняемый объект в виде структуры.
    Процедура СохранитьОбъектВХранилище(Префикс, UUID, СтррОбъект) Экспорт

    СохранитьЗначениеНастройки(Префикс + Строка(UUID), СтррОбъект);

    КонецПроцедуры

    // Сохраняет значение настройки в ХранилищеСистемныхНастроек.
    // Параметры:
    // ИмяНастройки - Строка - название настройки.
    // Значение - Произвольный - значение настройки.
    Процедура СохранитьЗначениеНастройки(ИмяНастройки, Значение) Экспорт

    ХранилищеСистемныхНастроек.Сохранить(КлючНастроекОбмена(), ИмяНастройки, Значение, , ПользовательНастроек());

    КонецПроцедуры
```

Я просто впервые вижу такой способ использования хранилища системных настроек. Т.е. фактически, для хранения новых документов используются не новые объекты конфигурации (как обычно это делается), - а непосредственно хранилище системных настроек.

Собственно говоря, вопрос: Насколько это целесообразно, вообще, с учетом того, что самих документов у организации может быть сотни тысяч (за пару лет работы), а может быть и больше. У меня есть задача, сделать регламент, который будет генерировать некоторые виды документов автоматом, по определенному алгоритму. И я как то "застеснялся" такой регламент делать, из за особенностей этой обработки. В общем нужен совет "бывалых"))

Я склоняюсь все таки к тому, что бы создать отдельный объект конфигурации (отдельный документ в конфигурации) и с ним уже работать. Но придется изменить алгоритм самой обработки для этого., что бы она работала уже не с хранилищем настроек, а непосредственно с самим новым документом.
---
1. Хранилище системных настроек - это таблица [dbo].[_SystemSettings].
То, что вы туда пихаете лежит в поле [_SettingsData] типа Image - т.е. это BLOB со всеми вытекающими затратами на хранение, извлечение и конвертацию в нужный тип 1С.

2. Надеюсь, объяснять, что вы теряете, используя вместо документов, какие-то структуры, хранимые в двоичных данных не надо.

3. У внешней обработки не так много вариантов сохранять свои данные, но один из самых неоптимальных - ваш вариант. Хотя бы потому, что вы пихаете множество данных в таблицу, где еще много всякого хранят всякие разные.

4. С вероятностью 99,9% - такое вот использование для множества документов - это плохая архитектура.
А при наличии расширений вообще надо хорошо подумать зачем такое вообще могло понадобиться.

Есть экзотические варианты, например, в области "защиты" данных хитромудрым разработчиком от вас. Своеобразный архив перед удалением и т.п. В эти дебри лезть желания нет.
Но и тут одно из наихудших решений - приведенное вами.

В общем, добрый совет - поймите задачу и сами разработайте архитектуру с авторами этой обработки лучше не советоваться.
---
Ну а где ещё внешняя обработка может хранить свои данные?
---
Здесь вопрос не в том, где хранить. Вопрос в том, как лучше хранить. Я могу понять, если надо сохранить настройки. Но тут то немного другая ситуация. Речь идет о тысячах документов. Я с таким подходом еще не сталкивался ниразу. Вот и написал сюда вопрос.

Вообще, есть где нибудь нормальное описание (именно техническое описание) хранилища системных настроек? Что это такое, где физически хранится, что там индексируется (и индексируется ли вообще), какие блокировки там работают, как работают и т.д. А то в интернете, кроме того, что это ужасно удобный механизм - вообще ни слова не написано (да и вообще, чуть ли не панацея от всех бед).
---
Вопрос в том, как лучше хранить. Лучше в базе. Но в таком случае обработка теряет свой универсализм, и начинает работать только в тех конфигурациях, где реализованы специальные объекты хранения, которые используются именно этой обработкой.
Отсюда возникает вопрос - а нахрена тогда держать эту обработку внешней? Пусть лежит рядом со своими объектами, и является единой подсистемой.

Нам не дано знать, какие были условия данной задачи. Может именно так и задумано было - некий скрытый от публики инструмент контроля, доступный только обладателю флешки с обработкой.
---
Вообще, есть где нибудь нормальное описание А зачем? Если ты не можешь его подстраивать под свои требования - то пользуй как есть. Или не пользуй.
---
А сколько документов уже создано? Их всех придётся пересохранять как обычный документ?
Это внутренняя самописка или решение от вендора?
Наверно должна быть какая-то предыстория, которая бы объясняла подобную архитектуру. Может, тогда расширений не было, а конфу нельзя было менять и т.д. и т.п. и какого-то потаённого смысла нет, а есть лишь маленькая записная книжка мерчендайзера или кого там.
---
какая-то предысторияСами ничего не осилили, сходили к руководству, узнали, почему оно не хочет оплатить абонемент, уговорили и скачали с инфостарта. Путь успеха!
---
Документов создано мало, - скажем так, количество документов несущественно для принятия решения по изменению архитектуры их хранения. Это решение от вендора, - именно это и напрягло меня.
---
Я понял. Это черная бухгалтерия. Доступ к которой имеет только человек с флешкой, на которой есть эта обработка.
---
1. Хранилище системных настроек - это таблица [dbo].[_SystemSettings].
То, что вы туда пихаете лежит в поле [_SettingsData] типа Image - т.е. это BLOB со всеми вытекающими затратами на хранение, извлечение и конвертацию в нужный тип 1С.

2. Надеюсь, объяснять, что вы теряете, используя вместо документов, какие-то структуры, хранимые в двоичных данных не надо.

3. У внешней обработки не так много вариантов сохранять свои данные, но один из самых неоптимальных - ваш вариант. Хотя бы потому, что вы пихаете множество данных в таблицу, где еще много всякого хранят всякие разные.

4. С вероятностью 99,9% - такое вот использование для множества документов - это плохая архитектура.
А при наличии расширений вообще надо хорошо подумать зачем такое вообще могло понадобиться.

Есть экзотические варианты, например, в области "защиты" данных хитромудрым разработчиком от вас. Своеобразный архив перед удалением и т.п. В эти дебри лезть желания нет.
Но и тут одно из наихудших решений - приведенное вами.

В общем, добрый совет - поймите задачу и сами разработайте архитектуру с авторами этой обработки лучше не советоваться.
---
Низкий поклон и благодарность. На мой вопрос - развернутый ответ.
---
фактически, для хранения новых документов используются не новые объекты конфигурации (как обычно это делается), - а непосредственно хранилище системных настроек.
Основная задача подобных "выкрутасов" максимально упростить внедрение обработки и снизить зависимость от конкретных конфигураций. В идеале, пользователи просто скачивают нашу обработку, добавляют в доп. обработки и пользуются. Без привлечения технических специалистов.

Само собой использовать подобные подходы на собственных проектах внедрения не нужно, за исключением использования готовых чужим обработок (например, интеграция с Диадок)
---
скачивают нашу обработкуАвтор?
---
Скорее всего именно из за этого и была создана обработка - универсально и независимость от любой конфигурации.
---
Автор?
Нет, конечно. Но подобных "выкрутасов" насмотрелся. Надеюсь, с появлением расширений будем видеть подобные извращения все реже.
Но например, задача автоматического обновления своего модуля успешно решается с доп. обработками. А можно ли автоматически обновить расширение не уверен.
---
с появлением расширений будемРасширения появились в 8.3.6.1977. Эта версия вышла в апреле 2015 года. 10 лет назад. Однако, "гениальных" выкрутасов и авторов,почему-то меньше не стало.
можно ли автоматически обновить расширениеМожно, конечно. В платформе есть все методы для этого. И опять таки приходим к выводу, что вовсе не в 1С дело.
---
Всем спасибо большое. Необходимые ответы получены.