|
Можно ли ввести более 6 видов времени в сводном "Табеле учета рабочего времени" ? | ☑ | ||
---|---|---|---|---|
0
raytan
12.06.23
✎
13:34
|
Есть ЗУП 2.5. Можно ли ввести более 6 видов времени в сводном "Табеле учета рабочего времени" для одного сотрудника в одном месяце?
|
|||
1
raytan
12.06.23
✎
13:36
|
Необязательно одним документом.
|
|||
2
Волшебник
12.06.23
✎
19:12
|
Согласовано.
|
|||
3
Гена
гуру
12.06.23
✎
20:18
|
(0) Нельзя.
|
|||
4
Гена
гуру
12.06.23
✎
20:34
|
Глянул релиз 130.2 - там нет ограничения в виде реквизита. Там просто тупо в десятках мест идёт одна и та же программная фраза для
ВидВремени1 ... ВидВремени6, Дней1 ... Дней6, Часов1 ... Часов6 Можно, конечно, подобавлять и 7, и 8 и т.д. во всех местах. Но зачем? И так сводный табель - это извращение, т.к. не позволяет корректировок задним числом. Поставили Я15 и 6Б в июне, а в июле выяснили, что он не 6 дней болел, а 5. И привет. Если уж 6-ти видов времени в месяце не хватает, то тогда уж наверняка надо переходить на нормальный подённый табель ) |
|||
5
НафНаф
13.06.23
✎
07:53
|
(4) "Там просто тупо в десятках мест идёт одна и та же программная фраза для
ВидВремени1 ... ВидВремени6, Дней1 ... Дней6, Часов1 ... Часов6" А - архитектура! |
|||
6
SleepyHead
гуру
13.06.23
✎
08:11
|
(5) 640 КБ хватит каждому.
|
|||
7
Chai Nic
13.06.23
✎
08:20
|
(5) Такой великолепный, отлитый в граните, код.
Но наверное это связано с тем, что нельзя сделать реквизит табличной части с типом "таблица значений". А неплохо было бы, кстати. Чтобы все типы 1с можно было штатно и без сериализации сохранять в базе, хоть списки, хоть массивы, хоть таблицы значений. |
|||
8
Гена
гуру
13.06.23
✎
08:50
|
(7) Представляете себе тогда размер базы? Тут уже были предложения сохранять чуть ли не по часам зарплатные данные для удобства будущего анализа. Лучшее - враг хорошего. Не спорю, когда в будущем, если останется человечество, возникнут квантовые компьютера с гугелевою памятью 10^100, то можно и каждую секунду в базу сохранять...
|
|||
9
SleepyHead
гуру
13.06.23
✎
08:55
|
(7) в версии 3.1 же сделали неограниченное количество показателей, связали с таблицей начислений. Это я про документ начисления зарплаты и прочих.
Но видимо на момент написания ЗУп 2.5 посчитали, что такого бардака, как 6 видов времени, быть не может нигде. |
|||
10
SleepyHead
гуру
13.06.23
✎
09:00
|
(8) А и сейчас не особо хорошо реализовано
Регистр расчета отдельно и в нем записи в разрезе месяцев начислений. В итоге сторнируешь начисление за часть месяца - и программа не понимает, как его учесть в НДФЛ, какой датой - аванса или зарплаты. Для расчета один регистр, учет аванса - второй, учет зарплаты за месяц - третий, данные для расчета больничных четвертый, для отпуска - пятый, для НДФЛ - шестой, для взносов седьмой.. везде практически одно и то же, в чуть-чуть разных разрезах, информация дублируется многократноЮ база пухнет на глазах. Я почему-то думаю, можно было организовать иначе. |
|||
11
Гена
гуру
13.06.23
✎
09:17
|
(10) Конечно, по уму надо было изначально делать.
|
|||
12
Chai Nic
13.06.23
✎
11:41
|
(9) Ну, можно конечно хранить связанные данные в дополнительных табличных частях, накладывая отборы по ключевым реквизитам. Но это получается "закат солнца вручную". На этом фоне бизнес-логика приложения просто теряется, и разработчик вынужден заниматься по сути низкоуровневыми задачами. Вообще, сделали же ТЧ объекта - новую костыльную сущность, почему бы было не сделать вместо этого просто возможность реквизита типа "таблица значений"? Да, это усложнит структуру хранения, но это же реально. Зато прикладная разработка упростится.
|
|||
13
SleepyHead
гуру
14.06.23
✎
15:00
|
(12) Ну как костыльную, по существу это отдельная таблица в базе данных. Она связана с объектом.
Чем принципиально будет от нее отличаться реквизит типа таблица значений? разве что платформенной привязкой к строке табличной части объекта... |
|||
14
Chai Nic
15.06.23
✎
08:26
|
(13) Костыльно то, что прикладному разработчику при разработке решения в объектной модели приходится забивать голову ещё и реляционной моделью, потому что полноценно объектную разработчик платформы не осилил.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |