Есть ЗУП 2.5. Можно ли ввести более 6 видов времени в сводном "Табеле учета рабочего времени" для одного сотрудника в одном месяце?

Необязательно одним документом.

Согласовано.

(0) Нельзя.

Глянул релиз 130.2 - там нет ограничения в виде реквизита. Там просто тупо в десятках мест идёт одна и та же программная фраза для
ВидВремени1 ... ВидВремени6, Дней1 ... Дней6, Часов1 ... Часов6

Можно, конечно, подобавлять и 7, и 8 и т.д. во всех местах. Но зачем?
И так сводный табель - это извращение, т.к. не позволяет корректировок задним числом. Поставили Я15 и 6Б в июне, а в июле выяснили, что он не 6 дней болел, а 5. И привет.

Если уж 6-ти видов времени в месяце не хватает, то тогда уж наверняка надо переходить на нормальный подённый табель )

(4) "Там просто тупо в десятках мест идёт одна и та же программная фраза для
ВидВремени1 ... ВидВремени6, Дней1 ... Дней6, Часов1 ... Часов6"

А - архитектура!

(5) 640 КБ хватит каждому.

(5) Такой великолепный, отлитый в граните, код.
Но наверное это связано с тем, что нельзя сделать реквизит табличной части с типом "таблица значений". А неплохо было бы, кстати. Чтобы все типы 1с можно было штатно и без сериализации сохранять в базе, хоть списки, хоть массивы, хоть таблицы значений.

(7) Представляете себе тогда размер базы? Тут уже были предложения сохранять чуть ли не по часам зарплатные данные для удобства будущего анализа. Лучшее - враг хорошего. Не спорю, когда в будущем, если останется человечество, возникнут квантовые компьютера с гугелевою памятью 10^100, то можно и каждую секунду в базу сохранять...

(7) в версии 3.1 же сделали неограниченное количество показателей, связали с таблицей начислений. Это я про документ начисления зарплаты и прочих.
Но видимо на момент написания ЗУп 2.5 посчитали, что такого бардака, как 6 видов времени, быть не может нигде.

(8) А и сейчас не особо хорошо реализовано
Регистр расчета отдельно и в нем записи в разрезе месяцев начислений. В итоге сторнируешь начисление за часть месяца - и программа не понимает, как его учесть в НДФЛ, какой датой - аванса или зарплаты.

Для расчета один регистр, учет аванса - второй, учет зарплаты за месяц - третий, данные для расчета больничных четвертый, для отпуска - пятый, для НДФЛ - шестой, для взносов седьмой.. везде практически одно и то же, в чуть-чуть разных разрезах, информация дублируется многократноЮ база пухнет на глазах.

Я почему-то думаю, можно было организовать иначе.

(10) Конечно, по уму надо было изначально делать.

(9) Ну, можно конечно хранить связанные данные в дополнительных табличных частях, накладывая отборы по ключевым реквизитам. Но это получается "закат солнца вручную". На этом фоне бизнес-логика приложения просто теряется, и разработчик вынужден заниматься по сути низкоуровневыми задачами. Вообще, сделали же ТЧ объекта - новую костыльную сущность, почему бы было не сделать вместо этого просто возможность реквизита типа "таблица значений"?  Да, это усложнит структуру хранения, но это же реально. Зато прикладная разработка упростится.

(12) Ну как костыльную, по существу это отдельная таблица в базе данных. Она связана с объектом.
Чем принципиально будет от нее отличаться реквизит типа таблица значений? разве что платформенной привязкой к строке табличной части объекта...

(13) Костыльно то, что прикладному разработчику при разработке решения в объектной модели приходится забивать голову ещё и реляционной моделью, потому что полноценно объектную разработчик платформы не осилил.