Идея проста - повысить управляемость произвольными вспомогательными текстами кодов на встроенном языке. Да, мы пишем их в УПОБ и прочих обработках, вводим в полях разовых блоков, но рано или поздно возникает нужда в библиотеке наработок, просто кусков исполняемого кода, решающих конкретные задачи. Одним из вариантов такой библиотеки является справочник алгоритмов в составе простенькой подсистемы. Основные его достоинства:
- Каждому куску кода, заслуживающему хранения и требующему использования, присваивается имя, уникальный код и идентификатор, снижается путаница и вероятность затереть новую версию старой;
- Все наработки могут быть упорядочены в папки, как в обычные группы справочника, повышается наглядность и управляемость библиотекой наработок;
- Данные хранятся в БД, риск потери наработок ниже, удобнее "передавать дела" коллегам; расширенные описания позволяют не забывать цели конкретных кусков кода, задачи, условия создания и применения;
- Можно использовать журнал регистрации 1С для отслеживания истории объектов;
- Можно ссылаться на алгоритмы из других реквизитов БД, хранить ссылки, гибче настраивать механизмы БД без переработки конфы, запоминать исключительные случаи, расширять функционал при минимуме затрат;
- Можно использовать собственный поиск и замену (средствами справочника), можно использовать полнотекстовый поиск.
- Есть простые инструменты (конструктор запросов, вставка терма "Значение"), сохранение отдельных алгоритмов в файл и открытие из файла (например, чтобы перекинуть из базы в базу по-быстрому, или прислать удалённому клиенту некую доработку для конкретной задачи).
Справочник может быть связан с другими объектами конфигурации, как обычные метаданные. Элемент справочника, конкретный алгоритм, может фигурировать в хранимом реквизите, решая конкретные задачи. Например: "алгоритм расчёта задолженности клиента", привязанный к группе клиентов; "алгоритм загрузки картинки", привязанный к номенклатуре; регламентные алгоритмы и многое другое. Не всегда эти вспомогательные куски кода имеет смысл пихать в конфу, иногда они часто меняются или являются разовыми костылями (нуждающимися, однако, в том, чтобы их применение спустя годы не забылось). Или, работа с клиентом не позволяет прислать cf/cfu-обновление, а внешняя обработка потом "потеряется". Хранение в БД поименованных алгоритмов помогает решить эти проблемы.
Алгоритмы можно вызывать один из другого, можно передавать любые аргументы на вход и получать данные на выходе. На входе у алгоритма - список значений или структура; на выходе - результат (его можно и не заполнять, если задача алгоритма в некоем действии, а не в получении конечного значения). Всё рассчитано и на серверное исполнение, и на внешнее соединение. Единственно - насчёт привилегированного запуска я ничего не делал, права рулятся на общих основаниях.
Наработка поставляется как подсистема с единственным справочником и демо-обработкой. Лично я давно уже просто копипащу справочник в каждую нужную конфу и всё. Никакие более механизмы ему не нужны, всё инкапсулировано.
По собственному опыту могу сказать, что использование справочника для организации собственных произвольных алгоритмов упрощает работу и делает многие процессы прозрачнее. Надеюсь, кому-нибудь такая штука тоже пригодится.