Типовая 3.1.27.93. Может кто сталкивался с такой ошибкой на bugboard:
- 01.10.23 прием на работу, отпуск за вредность есть
- с 10.10.23 по 31.10.23 временный перевод на позицию без отпуска по вредности
- с 16.10.23 по 22.10.23 временный перевод на позицию с отпуском за вредность
- 01.11.23 возвращение на основное место (окончание временного перевода), отпуска за вредность нет

Точно такая же картина и с разрядом (категорией).

В какой-то из веток на этой неделе подобное обсуждали.

(2) Оно - 1С ЗУП 3.1.27.92 временный перевод разрывает увольнение ?

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

(3) Да, там не про вредность, но что-то со временными переводами глобально напутано в ЗУП

(4) картинку, плиз, этого РС. Только захватите и графы использования по окончании.

(6) https://ibb.co/Bcjyk3F

(7) и ещё: РС Занятость позиций ШР интервальный

Впрочем, понятно, что там всё нормуль.
Давайте подумаем. Те РС, которые интервальные - они прекрасно отрабатывают всякие вложенные изменения реквизитов. Именно потому, что интервальные.
По отпускам такого интервального РС не предусмотрено. Следовательно, всегда (почти) работает последняя запись,  а там прописано, что вредность прекращается по её окончании. И по фигу, что выше есть запись о продолжении по бОльшей дате. Нет интервального регистра.

Обход понятен. Завести ещё одну запись, чтоб именно она была последней, где вредность есть. Например, доком Ввод остатков отпусков с 01.11

Но раз Вы просто тестируете базу, то надо понимать, что вредный отпуск даётся по ФАКТИЧЕСКИМ часам работы во вредных условиях. Не нужно отменять и заново вводить право на вредный отпуск при каждом перемещении. Умная программа и так увидит отсутствие вредности на новом рабочем месте и просто НЕ ДАСТ за это время вредный отпуск. Согласитесь, что это один к одному, как Вы зачем-то убирали право на него на время перевода. Ведь и так, и так будет ноль. You see?

(8) https://ibb.co/kJMxMgw

(10) ГБ - сторож?!
Уберите немедленно!

Шутка )
Ну да, интервальный регистр нормален.

(9) Я не тестирую. Я смотрю типовую. У нас десятки таких переводов в месяц (например, разливщика стали временно переводят в сменного мастера). Плюс точно такая же картина по разрядам - один в один.

(12) По разрядам тоже нет интервального регистра.
Хотите - заводите свои.
А если по лени, то достаточно внешнего отчёта, который выводит такие бяки. И тогда вводить ещё одну запись.

Либо запретить КП, у которого дата окончания меньше предыдущего. Закрывать раньше предыдущий, проводить текущий и снова открывать предыдущий.
Как-то так. Грустно? Но нет идеала в нашем мире, увы...

Ладно, написал на [email protected] посмотрю что ответят. Вручную ограничивать "большой" временный перевод или ручками назначать право на отпуск после его окончания как-то не хочется.

(14) Ответ потом, пожалуйста, сюда. Мне интересно как они отпишутся )

(15) Хорошо

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

(14) интересная тема, сталкивался с таким. Ждем ответ от разрабов.

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

(14) (15) (18) Только просьба делать это своими словами. Нельзя выкладывать переписку от фирмы 1С в публичный форум.

(14) А если делать не временный перевод, а два перевода, то корректно работает?

Вместо 01.01.2023 - 10.10.2023 на сторожа сделать два

1. с 01.01.2023 - сторож
2. с 11.10.2023 - ГБ

(14) Мы не можем ждать милостей от природы фирмы 1С; взять их у неё — наша задача (с) И.В.Мичурин

Заинтриговал меня автор и я начал думать. Исторически так сложилось в 1С, что РС формируются отрезком, т.е. одним интервалом, определяемым реквизитами «С» и «По» своего регистратора. Причём последний делает две записи в РС (изначально действует Сведение_1):
ДатаРегистратора … Дата начала … Сведение_2
ДатаРегистратора … ДатаКонец + 1 … Сведение_1
т.е. во второй записи возвращается Сведение, действовавшее до регистрации изменения.
|0000000000|000000000000|000000000000...

Теперь мы внутри (или с пересечением) первого временного изменения добавляем второе временное изменение сведения:
ДатаРегистратора … Дата начала … Сведение_2
ДатаРегистратора … ДатаКонец + 1 … Сведение_1
ДатаРегистратора_2 … Дата начала_2 … Сведение_3
ДатаРегистратора_2 … ДатаКонец_2 + 1 … Сведение_2
|0000000000|000|0000000|00|00000000000...

Видно, что такой отрезковый подход приводит к ошибке: в последней записи до конца времён будет работать Сведение_2, а надо, чтобы после ДатаКонец > ДатаКонец_2 заработало Сведение_1:
|0000000000|000|0000000|00|00000000000...

Что же делать? Если пойти путём трёх записей одного регистратора, то данная конструкция не сработает для неизбежных правок кадровиками своих документов задним числом. Придётся тогда восстанавливать последовательность КП, а за такую идею кадровики просто уволят программиста )

Другая идея, и судя по всему, верная – ввести новый РС, интервальный. Он должен работать так: никакого регистратора, собирает данные исключительно из родного РС и к себе записывает их в  строгом интервальном порядке. При любом изменении любого регистратора – подаётся команда на ПЕРЕЗАПИСЬ полного интервала, т.е. меняются все его записи. Согласитесь, что таким образом кадровики могут хоть сто раз на дню менять, удалять, заводить свои кадровые документы. Новый интервальный РС (ИРС) всегда готов как пионер.

Глянем теперь конфигуратор ЗУПа. Действительно для десятка РС существуют их братья ИРС. И выяснилось, что программисты 1С всё-таки умные люди. Они реализовали ИРС так универсально, что достаточно просто сделать брата любому РС, хоть всем ста (или сколько их там). По концовке имени регистра «Интервальный» общие модули его распознают и начинают работать с ним, а не с его основным. Понятно, что у ИРС должны быть как минимум все измерения, ресурсы и реквизиты основного собрата. Плюс свои дополнительные.
Опущу подробности, но схема создания нового ИРС следующая:
1.    Скопировать любой ИРС, например по графику
2.    Назвать строго ИмяОсновногоРС + «Интервальный» и тогда при включённой константе интервальности заработают общие модули и на автомате вместо основного РС будут работать с его ИРС.
3.    Модуль менеджера там маленький – в одном месте поменять график на имя своего основного РС
4.    Аналогично в Данных поменять один ресурс
5.    С новым ИРС всё.
6.    В основном РС добавить только три маленькие процедурки (скопировать из любого другого ИРС)







От силы час работы. Или если есть хозяева на форуме – то можно дать старшему помощнику младшего программиста.

Какой профит? Кадровики народ неугомонный. Сегодня допотпуска мерцают у них в КП, завтра разряды, послезавтра ещё что. А тут будет готовый механизм для их будущих хотелок. Ну и на инфостарт можно выложить в виде расширения. Да и вообще – интересно чисто с научной точки зрения )

(15) https://bugboard.v8.1c.ru/error/000132071

Кратко - признали ошибкой и положили ящик.

(25) Ответ в (22)

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

(27) Не так. Интервальный функционал вроде работает. Просто из ста с лишнем РС обинтервалили только 11. Остатки отпусков не входят в круг избранных, вот я и предложил Вам сделать это.

Когда сделаете, то и для разрядов тоже. Кутить - так кутить.

(25) "Кратко - признали ошибкой и положили ящик."

Проголосовали, что исправление ошибки важно?
Поставил на всякий случай и мой голос тоже.

Ну и что мешает проверить (21), так и не понял. Моих всех научил так делать вместо временных переводов, тем более, что сейчас можно проставить номер первичного приказа в отдельное поле.

И для отчетности в СФР удобнее. Один минус - могут забыть, но это уже меньшее зло, чем все остальное.

(29) Конечно корректно. Только так никто у нас не разрешит. Это получается надо ограничить "длинный" перевод. Он изначально согласуется в ЭДО, потом падает на исполнителя. Тот забирает его себе в работу и отрабатывает в ЗУП. Там формируется печатная форма, которая улетает в ЭДО, фронт-офис ее распечатывает и подписывает у сотрудника. После в ЭДО возникает "короткий" перевод. Он отрабатывается кадровиком (тот вообще не думает - пришла задача - взял - исполнил - закрыл - взял новую). И мне получается надо тут вклинить ему задачу ограничить "длинный" перевод, а потом его продолжить по окончанию "короткого" ну и заодно переформировать ПФ и заново ее переподписать у сотрудника. Мне скажут исправляй, что и запланировано на ноябрь.

(30) Мда, как сложно все у вас...

Прошла неделя с ТЗ, описанном рыбно в (23). Вместо того, чтобы засучить рукава и потратить малую толику времени на ИРС по остаткам отпусков, автор занимается перепиской с фирмой 1С. Интересно, все программисты 1С теперь такие или же это исключение? Вот то ли дело раньше, когда небо было голубее, трава зеленее и типовой код не воспринимался как скрижали Моисея... Эх-хе... (

(32) Так перфекционизм же это плохо? Их надо всех выгонять же? А тут вы настаиваете на серьезной работе. И кто вы после этого?! ))

(33) Лучшее - враг хорошего.
Но когда сделано плохо, то надо сделать хорошо.
You see?

(34) Хм, ну так я того же принципа придерживаюсь.

Но в некоторых случаях все сделано настолько плохо, что надо сделать хотя бы хорошо. А вы меня за это....

(35) Да ладно. Я ж шутейно. Такие люди очень нужны в любом коллективе, потому что большинство не любит проходить натфилем после рашпиля.

(30) А как в этой задаче с применением ЭДО отрабатывается ситуация, что в начале перевода надо подать в СФР документ СЗВ-ТД на дату начала, а на дату окончания пока не надо?