простая вродебы задача - создал настроечную таблицу, нужно к ней наворотить обвязку (т.е. транзакцию ведения, чтобы юзеры могли редактировать в ней записи). Табличка простейшая, с другими несвязана, только NUMC и CHAR-поля для ввода.
Есть чтото типа быстрого конструктора форм (wiazrd? ), чтобы пихнуть в него таблицу, а он бы программный обвес выдал? Или с нуля на ALVшке воротить (через правку копии во внутренней таблице и ее синхронизацией с БД)?

Утилиты - Генератор ведения таблиц

В SE11

Если у тебя версия 4.6 и выше, то посмотри Тр. SE16N,
и ФМ SE16N_INTERFACE

Обрати внимание на кнопочку "Правка" у своих сообщений .

ЗЫ. Да я и сам не сразу дотумкал .

А я и не смотрю туда
Ладно буду знать, хоть очепятки поубирать можно...

SE16N не подошел (лишние поля на экране, интерфейс какойто необычный получается)

по генератору вопрос: сгенерил он мне 2 ФМ, не совсем понятны 2 момента:
1. как их правильно вызвать из своей программы? Получилось только через создание отдельной транзакции (SM30 с параметрами, как описано в справке по SE54). В частности, там несколько внутренних таблиц надо на входе в ФМ чемто заполнить - чем? И будут ли какие приеимущества при таком прямом вызове?

2.группу полномочий как выбирать? Выбрал "ведение таблиц" - оно при входе ругается "мандант имеет статус неизменяемо" Это глобальная настройка (т.е. протестировать ведение в dev-манданте нельзя) или изза неправильной группы полномочий такое?

1. Да, через вариант SM30, и вызывай через call transaction
2. Это зависит от свойств твоей таблицы,
измени "Ведение брауз.дан/ракурса табл."
на "Просмотр/ведение разрешены" и проблема должна сняться.
Если нельзя менять , то есть еще способ...

К примеру:

1. создай транзакцию параметра
2. в поле 'транзакция' укажи 'sm30', установи флажок 'Пропустить нач. экран'
3. Значения по умолчанию:
VIEWNAME = имя_ракурса_ведения
UPDATE = X

и все, теперь для ведения таблицы запускай эту транзакцию

спасибо, разобрался - в тестовом манданте ведение нормально работает ....
А будут-ли исправления правильно транспортироваться в продуктив при этом? Т.е. нужно-ли еще какой наворот туда дописывать, чтобы всё что юзеры "навели" в настроечном манданте, правильно транспортировалось? Или там уже всё включено?

Если необходимо, чтобы произведеные изменения цеплялись в запрос, нужно в "Генераторе ведения" выбрать "Стандартная подпрограмма записи"

Да нет. Только с базисом еще поговори.

Если тип данных настройки, то может ругаться на закрытый мандант. Я делаю тип "А" - основные данные вроде не ругается.

Хотя повторюсь тут все зависит от настроект базисса.

тут другое интересно,
как "Моменты времени",
а которых на разные события можно
прописывать свои подпрограммки проверки,
можно и сгенерированные экраны менять без ключей...

Кстати по моментам времени - куда нужно вставлять свою дополнительную проверочку на введенное значение поля? Да еще с нормальной обработкой - выдачей сообщения об ошибке и позиционированием на нужную строчку? (аналог стандартной проверки на дублирующийся ключ )Эвентов много, но что-то нужный не находится

и правда транспортируются

вцелом понятна. Теперь вот какая беда: создал я view объединяющий 3 таблицы (для их совместного ведения), ну примерно так

ztabl1
cod1 text1

ztabl2
cod2 cod1 text2 -связана много-1 с ztabl1

ztabl3
cod3 cod2 text3 -связана с ztabl2

для упрощения вывел в view все поля таблиц, включая текстовые (наименования позиций). После генерации "ведения" оказалось что оно предлагает мне заполнять ручками все поля, включая текстовые.
Но мне хотелось бы, чтобы тексты тянулись при вводе ручками поля cod из соответствующей связанной ztable-справочника, и были readonly (т.е. фактически чтобы юзер быстро и удобно мог добавлять записи в ztabl3, при этом допустимые значения cod2 и cod1 сверялись бы с ztabl2 и ztabl1) .... Как при генерации ведения view указать, какие поля для ввоода ручками, а какие должны только подлягиваться через inner join?