Здравствуйте.

Если тема не по адресу, прошу модераторов перенести в нужный раздел.

Вопрос в следующем. Можно ли добавлять пользовательские поля в настроечные таблицы?
Напримет таблица T161 - Виды документов закупки. Мне нужно добавить туда поле ZZSTSMA Статусная схема.
По аналогии со сбытовыми настройками.

В SE11 создать дополнительную структуру для таблицы T161 система позволяет. Нужен ключ разработчика.
Для ведения поля создам свой ракурс к стандартной таблице. Создавать отдельную таблицу для ведения этой настройки смысла большого не вижу.

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

Сам не разработчик, поэтому проверить на системе не могу
А перед тем как писать ТЗ, хотелось бы понять, реально это вообще или нет.

Гугл не помогает поэтому буду рад, если поделитесь соображениями.

Да в принципе конечно можно. Мы тут на свою голову допустили такое для таблицы T001L
Только чем не устраивает отдельная настроечная таблица:
-ракурс ведения все равно отдельный, через SPRO своего поля все равно видно не будет.
-при создании свей таблицы добавляется возможность указать доп.ключевые поля (например для разделения по орг.единицам)
-нет головной боли для базисников при установке патчей/апгрейде

Какие конкретно проблемы вы заполучили после T001L ?

Почему мне больше нравится расширение:
* При утере документации, или со временем когда уже забудется что такая доработка есть. Я при при просмотре Т161 в SE11 увижу поля. А потом в SM30 по имени таблицы найду ракурс. В случае своей Z таблицы, только код анализировать. Плюс все таки таблица = сущность, а тут сущности нет, а таблица выделяется.

* Доп. ключевые поля не требуются.

* Насколько я понимаю, при расширении таблицы без модификации в правильном нэймспэйсе никаких головняков при обновлении быть не должно.

1.А кто мешает сразу ракурс ведения Z* в SM30 посмотреть? вообще-то T*-таблиц как правило намного больше, чем Z*-настроек. Если конечно на каждый чих Z-таблицы не создавались
2.Никто не мешает найти таблицу по нужному ЭД
3.Можно свои настроечные таблицы запихнуть в отдельную ветку SPRO и задокументировать, чтобы бумажки с документацией не потерялись.

Пока оба варианта одинаково приятны, но все говорят делать по старому, как привычней
Почему - не понятно.

Сроки?

Сроки пока не сильно жмут, попробую расширить таблицу.

Спасибо.

Но мне по прежнему не понятно зачем создавать отдельную таблицу для хранения полей?
Если расширить стандартную, и создавать свой ракурс ведения, то эффект тот же, а таблиц меньше.

В чем принципиальное преимущество отдельной таблицы?

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

to Удав, Я так понимаю расширяли t001l для наименования склада, потому что 16 не хватает? Если да, то как полет?

Нет, добавляли доп. классификацию складов (центральный, цеховой, воспомогательный и т.п.). Один раз для всех складов настроили (структура уже устоялась) и забыли.
А полное наименование склада можно прописать в адресах складов

Опасность в новом ракурсе состоит в том, что будет сложно искать все запросы, в которых изменялись любые данные склада.
Стандартный ракурс то никуда не выкинешь из SPRO

Поэтому в новом ракурсе определили только ключевые поля и поля, которых нет в стандартном ракурсе. После этого поставили статус ведения "Считывание и изменение".
В результате добавление новых складов контролируется по IMG, добавление классификации идет отдельно, через свой ракурс.
Кроме этого, в T001L после апгрейда на ERP появились новые поля.
Если бы мы сделали единый ракурс для ввода данных - пришлось бы перегенерировать свой ракурс ведения...

Нормальные люди так не делают. Это аксиома