Вопросик такой ... в разработке запланировано использование таблиц, содержащих некоторые настройки. Вроде бы логично сделать их настроечными. НО ... это значит, что все настройки прийдется создавать в манданте разработки и тащить до продуктива. Возникает дилемма:
1. Сделать таблицы прикладными, что позволит ускорить время их настройки в продуктиве, но затруднит тестирование изменений до переноса в продуктив.
2. Сделать таблицы настроечными, что снимат все возможные заморочки с тестированием изменений, но увеличит время внесения новых настроек в продуктиве.

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

А как происходит на практике обычно, всё стараются сделать прикладным для "ускорения и простоты"?

Прим. Интересуют не рассуждения, а именно текущая практика, т.е. "срез реальных ситуаций".

У меня на старой работе все Z... таблицы делались А и, в соответствии с потребностями, выбиралось, разрешена ли maintenance или нет и прочая. Таблицы, которые должны быть сразу заполнены какими-то данными, обычно очень небольшие и данные можно легко перенести с помощью copy/paste.

На новой работе некоторые таблицы были сделаны С (по неизвестным причинам) и, когда пришлось для них делать maintenance, то это, честно говоря, был геморрой, хотя и небольшой.

В общем думаю надо, в первую очередь, руководствоваться тем, нужно ли вам будет изменять данные непосредственно в продуктиве или нет. Чистое IMHO, конечно.

Практика очень простая - если заведение данных будет поручено конечным пользователям - тогда класс A. Если таблица базируется на других таблицах класса A - класс A (хотя обратное C->C совершенно необязательно). В остальных случаях предпочтительней сделать класс C. Но в любом случае каждый вариант следует рассматривать индивидуально.
Что касается скорости - то следует учитывать возможные влияния изменения настрек на смежные модули и желательность тестирования выполняемых изменений. И поэтому лкчше спешить не спеша. Так же следует принимать во внимание тот факт что, как правило, разработчиков и консультантов не пускают в продуктив (или пускают, но с правими на просмотр). Поэтому никакого ускорения в сравнении с вариантом с переносом нет.

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

Вот при копировании мандантов или импорте данных класс поставки действительно важен.

Добрый день!

не подскажите, где можно найти информацию по видам таблиц? вы упоминали A и С, еще z... отчеты. Что это и какие еще есть?
Не подскажите еще английские названия для них

Попробуйте точнее сформулировать вопрос.
Выше в теме обсуждали класс поставки (Delivery class) таблиц. Хелп по нему. В принципе, там же можно найти и остальную информацию о параметрах таблиц в словаре данных.
Так же, информацию можно получить непосредственно в тр-ции словаря данных, нажимая F1 на интересующем поле.