Как правило в каждой разработке существуют какие-то параметры для ее работы. Вопрос, как их вести?

Везде где я видел эту проблему решают творчески с примесью бардака:
1. Основные параметры типичной программы понятное дело задаются на селекционном экране. Однако, к сожалению, далеко не всё можно там разместить: в силу объема этих самых параметров, неудобства для пользователей, запуске парограммы в фоновом, асинхронном режиме (особенно при интеграции с другими системами).
2. Редко меняющиеся штуки задают константами в коде (в верхушке *_TOP), особо продвинутые создают type-pools и тянут их в каждой программе.
3. Для данных которые можно хоть как-то структурировать делают отдельную табличку. Естественно со стандартным неудобным ракурсом ведения. Разумеется историю изменений никто не делает, полномочиями не органичивает.
4. То показалось самым основным/важным - добавляют в SPRO.
5. Что-то выносят в параметры пользователя.

Интересно, как эту проблему решают остальные сапёры? Разрабатывают свою систему ведения парамеров: удобную, с полномочиями, логами?

Кластеры и программка c кнопками их вызова Z<что-то там>_conf

viewtopic.php?f=13&t=75389&start=0

В принципе стандартный ракурс ведения для подобных зависимых от времени параметров удобен. Предложенный мне SAP-стандартный метод метод Aleqs-ом показался рациональным. Теперь применяю его, история при этом ведется SAP-ом. Все периоды хранятся, полномочия можно уже самому вставить через события генератора ракурся.

А чем это лучше использования стандартного инструмента добавления своих настроек (ракурс, кластер ракурсов, транзакция) в SPRO?

История изменений для любой таблицы активируется в технических параметрах таблицы.

Вот еще несколько вариантов:
6. Наборы GS01-GS03. Ведется история изменений, можно переносить запросом, ограничивать полномочия
7. Тр. STVARV. Меньше возможностей по сравнению с наборами
8. Глобальный класс с константами. Упрощает жизнь программистам - всегда можно посмотреть что где используется, но для ведения нужен ключ разработчика. Ну и переносится весь класс целиком, поэтому подходит только для редко меняющихся настроек

И профильный параметр rec/client тоже должен быть включенным.

Да собственно ничем. Удобно в одной программе иметь все настройки. К кнопкам можно привязать как стандартные транзакции настройки (как пример dmwb и srm_regedit), так и свои z-настройки

Так оформляйте документацию к программе со ссылками на SPRO.

Как говорят классики- "Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему".
Общего решения в виде чёткого и однозначного "делать так так и так" нет.

Так как "параметры для работы" во первых делятся на "настройки" и "основные данные" - т.е. ведутся в системе разработки и переносятся в продуктив илиопределяются непосредственно в продуктивной системе.
"параметры для работы" могут и не быть простыми параметрами, а зависеть от других параметров - БЕ, орг.присвоения, полномочий, способа вызова транзакции\отчёта и прочего и прочего.
Так что попытка сделать некую универсальную "систему ведения парамеров: удобную, с полномочиями, логами" обречена.
И отдельно:

Далеко не для всех данных стандартный ракус не удобен.
Стандартный ракурс уже хорош лишь потому что он стандартен - т.е. имеет знакомый интерфейс и поведение, как в других же стандартных ракурсах.
Что до "разумеется" - то это претензия не к инструменту, а к тому, кто "разумеет" - не задаёт соответствующие опции, не указывает объекты полномочий и пр.

На текущем проекте предшественники создали такую вещь:
глобальная настроечная таблица для всех программ
Реализован интерфейс создания и ведения настроечных параметров. Пользователь нажав на соотв. кнопку тулбара стандартного экрана выбора видит еще один экран выбора сгенерированной программы.

Искреннее любопытство автора: на каких проектах работает ZSPS?

а что такое ZSPS?

тут это называется по другому. Реализовано в 2003 году. Русал

System of Saved Parameters (или Saved Parameters System - по крайней мере я так задумывал) - в различных вариациях (ZSSP, ZSPS, и т.п.). На русале рука дрогнула - группу функций сервисов SPP обозвал переименовывать уже не стал.
Суть не меняется - описание параметров со ссылкой на тип СД + динамический экран параметров + кластерная таблица значений. Все это обернуто в диалог + класс считывания + ФМ сервисов (вызов с экрана параметров отчета, сохранение в запросе и т.п.)... Ну и, конечно, проверка полномочий - ее часто отключают

что скажу - все работает и активно используется, полномочия в том числе.

ИМХО:
1. Технический аспект ведения параметров абсолютно не важен
2. Важно единообразие в рамках проекта и наличие регламентирующего документа для разработчика/документации для пользователей