Зуп 3.1. Работающие сотрудники #807980

Уважаемые специалисты! Подскажите пожалуйста, как выбрать работающих сотрудников на конкретную дату. Желательно какой запрос. Или хотя бы какой регистр?

РС КадроваяИсторияСотрудников

Пользуйся общим модулем "КадровыйУчет", функцией "КадровыеДанныеСотрудников", почитай в общем модуле, как ею пользоваться. С ее помощью получай дату приема и дату увольнения, и смотри, как они соотносятся с твоей датой.

Вот примерно так:

> Вот примерно так: во времена 8.0 за выгрузку в ТЗ и перебор циклом сразу линейкой по рукам давали.

Вам с шашечками или ехать? Ну наверните крутой запрос, только вангую, по времени исполнения будет так же, а на разработку времени затратите больше. Можно по регистру ТекущиеКадровыеДанные сделать, но тогда на заданную дату не получится.

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

> Вам с шашечками или ехать? я грамотные запросы уже много лет пишу >  наверните крутой запрос, только вангую, по времени исполнения будет так же, а на разработку времени затратите больше. грамотный запрос один раз написать надо и потом везде можно использовать. > И кроме того, функции этого модуля используются в стандартных кадровых отчетах. понятна причина тормозов третьего зупа. > Идите дайте линейкой нынешней команде разработчиков ЗУП 3. подозреваю, что даже если будет такая возможность, то это вряд ли им поможет правильно программы делать.

Человеку похоже надо разово решить проблему. Что-нибудь слышали о соотношении затраченных усилий к полученному результату?

Тебе для СКД или для обработок? Вот запрос для СКД из типового отчета КадроваяИсторияСотрудников: ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ     Сотрудники.Ссылка КАК Сотрудник,     "ТолькоРазрешенные" = ИСТИНА Только не забудь в модуле отчета добавить: Если для обработок, то как в , хотя есть и другие методы. Но просто и по одной таблице сейчас не получится. Документации нет, только смотреть примеры в типовой конфе.

"грамотный запрос один раз написать надо и потом везде можно использовать. " Какая наивность.. Смена структуры данных в очередном релизе и он уже не работает.

+ посмотрел в отладчике, что получилось из запроса в после замены по шаблону и опупел .

А представь, как девочка автор опупеет.

еще забыл, в в модуле отчета конечно же самое главное:

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

Почему нельзя сделать так?

Партнеры с опытом работают, а не на партнерках отвечают - для этого там фирма 1С есть. А какую документацию то надо? "Список работающих сотрудников можно получить так"?. Да и куча ньюансов все равно, некоторые конторы договорников считают сотрудниками, некоторые внутренних совместителей не учитывают и т.д...

выпустить методичку или на ИТС статью. Для регистров, у которых естьпарный регистр Интервальный, есть такие то методы, имя метода так-то составляется. Для учета рабочего времени есть такие программные интерфейсы, для планового такие. итд. Но структурированно конечно надо все прописать. Очень много времени уходит на просмотр общих модулей и примеров кода в типовой. Еще и не все методы имеют подробный комментарий.

А когда такое вообще было? Ни разу не видел методичек по коду

> Что-нибудь слышали о соотношении затраченных усилий к полученному результату? учиться нужно всегда правильно. а для зарплатчика запрос по сотрудникам - основной запрос, если эти уж такие запросы будут через одно место, то все остальное тоже можно выбрость. > Какая наивность.. Смена структуры данных в очередном релизе и он уже не работает. это отмазка твоя. я не верю, что разработчики из 1с настолько без головы, чтобы структуру от релиза к релизу менять.

+19 причем структуру основных регистров программы, которой уже не первый год.

Да им давно пора доской по морде

Можно поинтересоваться у сообщества, чем плох такой простенький запрос. КадроваяИсторияСотрудниковСрезПоследних.Сотрудник, КадроваяИсторияСотрудниковСрезПоследних.Подразделение, КадроваяИсторияСотрудниковСрезПоследних.Должность, КадроваяИсторияСотрудниковСрезПоследних.Сотрудник.Код p.s как это оформить как код на форуме? Спасибо.

поменяли же, причем с год назад всего, при выпуске 3.1.1 или 3.1.2. Это когда интервальные регистры появились. Поэтому разработчики и не рекомендуют напрямую с регистрами работать. Логику работы того, что реализовно в типовой иной раз сложно понять. А пояснений очень мало. Например я недавно узнал что, что в регистр ГрафикиРаботыПоВидамВремени записи по сотрудникам пишутся при расчете документа Начисление зарплаты. Не при записи, не при проведении, а при расчете.

по интервальному регистру лучше собирай. в обычном данных может не быть

а как же события ДО?

Очень приглянулся 22. Там и основных можно отобрать. 25- что может быть не так?

я как-то так делал. если есть что поправить - пишите. 10 минут прибавлял, так как там не на начало дня запись в интервальном, а с секундами

ну и ГДЕ заменить на

ГДЕ

вот пример из интервального по одному сотруднику, для которого сделали временный перевод с 01.06 по 25.06 Секунды и минуты в периодах доставляют.

как я понял, там у приема + 20 сек, у перевода + 60 сек, потому накидывал 10 минут на всякий пожарный. но да, Л - логика на мой взгляд надо руки пооткрывать тому, кто придумал так код в типовых писать. 10 переходов между функциями, чтобы 1-2 строки кода получить в итоге. в результате отладка чего-то сколько-нибудь сложного превращается в аттракцион -я путешествую по всем модулям конфы, в процессе уже и забыл зачем путешествую. если делается это для 1 раз сделал и больше никогда не возвращаться - читайте советы выше и делайте, как в типовой. иначе смена релиза - и новые ингральные и синусоидальные регистры и все переделывать

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

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

можно уточнить, что там за события такие? кроме приема, перемещения и увольнения? Причем в день одно событие только может быть по большому счету. если боитесь наплыва событий, делайте вызовом типовых функций. у меня только сейчас появилась возможность рефакторингом кода заниматься, а в начале года, когда 3.1 внедрялся, время было набросать запрос, проверить, что данные нормально возвращает, и в работу его

на одну дату можно оформить более одного документа того же самого перемещения. Актуальным будет самый поздний. В регистр они попадут одной датой, и различаются только секундами. Так что я не боюсь, а предостерегаю остальных от возможных ошибок: при получении среза, подставляйте в параметр конец дня, а не взятые с потолка +10 минут.

> на одну дату можно оформить более одного документа того же самого перемещения. а можно узнать, какой практический смысл в этом?

вот пример с реальной рабочей базы: перемещение с 01.07 в регистре делает запись с датой начала 01.07.2016 0:01:00, дата окончания 3999 год. потом проводят еще одно кадровое перемещение, эта запись с 3999 годом заменяется на дату окончания 03.10.2016 0:00:59, следующая запись начинается с 03.10.2016 0:01:00 и это уже новое кадровое перемещение. что тут за логика - вопрос к 1С. получается если смотреть на 03.10.2016 0:00:20 он вроде как в старом подразделении все еще числится, хотя по факту он уже в новом. возможно лучше делать срез на конец дня, я не проверял, будут ли там какие-то еще нюансы

Например одним кадровым приказом изменили оклад. Вторым перевели в другое место, где полагается еще какое нибудь плановое начисление, а наравне с ним в таблице снова фигурирует оклад. Получается на одну дату ты проводишь изменение оклада два раза.

посмотрел, похоже так правильней будет, исправлю, спасибо. как-то так должно быть

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

Если ваш запрос возвращает две строки - это неправильный запрос.

проверил, да, нормально так. первое кадровое перемещение просто утрачивает всякий смысл так как по нему запись с даты начала 07.11.2017  0:01:00 по дату окончания 07.11.2017  0:01:00, в результате в запросе будет одна строка - по последнему кадровому перемещению

Но в данном случае должно быть все ОК ))

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

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

Да все можно, только кто это оценит из пользователей? Я уже понял, что некоторым объяснять бесполезно, но вам попробую. Что важно для пользователя? Чтобы ему решили проблему, и это решение работало всегда. Да, мое решение далеко неидеально с точки зрения производительности, зато оно опирается на использование общих модулей, работоспособоность которых гарантирует разработчик. При смене релиза результат работы не изменится, отчет будет работать в точности так же, как ранее. Если меняется структура регистров (а она меняется постоянно), то может наступить момент, когда ваш запрос перестанет работать. И все, переписывайте заново. И я на сто процентов уверен, что крутые запросы тов. Kumena никто из пользователей оценить не сможет, да и не собирается. Никто не будет делать замеры производительности и аплодировать тому факту, что запрос этого программиста работает на полсекунды больше, чем процедура из общего модуля.

> Получается на одну дату ты проводишь изменение оклада два раза. еще раз, какой в этом смысл? в Т-2 одно изменение на дату, в начислении зарплаты тоже. > работоспособоность которых гарантирует разработчик. им давно уже верить нельзя, придет другая команда и все переделает, и клали они на обещания предыдущей.

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

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