Заметил, что в документе «Кадровое перемещение» при подборе сотрудников не всегда во вкладку
«Начисления» попадают все начисления сотрудника. Начал ковырять сначала пользовательские настройки
и последовательность заполнения всех документов, параметров учёта и т.д…
Выяснил, что эта фигня наблюдается только при наличии штатного расписания 
Причём, если штатное расписание по должности нужного сотрудника заполнено ПОСЛЕ даты документа
«Кадровое перемещение организации», всё работает отлично. Если же штатное расписание заполнено в
тот же день или ранее, начинаются глюки. Стало интересно… оказалось, что не только в этом документе
наблюдается данный глюк.
После этого пошли ковыряния в конфигураторе… Нашёл )))) Оказывается в одни и те же поля в разных кусках запроса
запихивается то 0, то NULL, а потом по этим полям идёт объединение. После чего в 14-м вложенном запросе и далее
нужные данные просто отсекаются.
Общий модуль «ЗаполнениеДокументовЗК». Там есть такая функция:
Функция ПолучитьТаблицуДействийСНачислениями(ДанныеДокумента, ДокументСсылка, ДокументДата, Организация, ИмяДатыДействия, КоэффициентИндексацииЗаработка = 1, ПоДаннымТрудовогоДоговора = Ложь, ПолучатьПлановыеНачисления = Истина, ОбособленноеПодразделение = Неопределено) Экспорт
Нужно найти все вхождения запроса где происходит «ВНУТРЕННЕЕ СОЕДИНЕНИЕ» по полям «Показатель1», «Показатель2»,… «Показатель6».
И добавить в сравнение проверку на NULL: ПоказательN -> ЕстьNULL(ПоказательN, 0)
Получается вот такое сравнение:
|ПОМЕСТИТЬ Начисления
|ИЗ
| НачисленияСтаройПозицииСрезПоследних КАК НачисленияСтаройПозицииСрезПоследних
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ НачисленияНовойПозицииСрезПоследних КАК НачисленияНовойПозицииСрезПоследних
| ПО НачисленияСтаройПозицииСрезПоследних.ВидНадбавки = НачисленияНовойПозицииСрезПоследних.ВидНадбавки
///<+ Автор=’Токарев Виталий’; 28.10.2011 18:31:11; Текст=»;
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель1, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель1, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель2, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель2, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель3, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель3, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель4, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель4, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель5, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель5, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель6, 0) = ЕСТЬNULL(НачисленияНовойПозицииСрезПоследних.Показатель6, 0)
| И НачисленияСтаройПозицииСрезПоследних.Сотрудник = НачисленияНовойПозицииСрезПоследних.Сотрудник
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ НачисленияСотрудника КАК НачисленияСотрудника
| ПО НачисленияСтаройПозицииСрезПоследних.ВидНадбавки = НачисленияСотрудника.ВидРасчета
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель1, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель1, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель2, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель2, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель3, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель3, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель4, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель4, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель5, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель5, 0)
| И ЕСТЬNULL(НачисленияСтаройПозицииСрезПоследних.Показатель6, 0) = ЕСТЬNULL(НачисленияСотрудника.Показатель6, 0)
// TVA/>
| И НачисленияСтаройПозицииСрезПоследних.Сотрудник = НачисленияСотрудника.Сотрудник
|
|ОБЪЕДИНИТЬ
Вуаля! Всё работает… Ну, соответственно, где есть неравенство «<>», тоже добавляем…





Спасибо.
Тоже заметил это через день после обновления. Вот только сел разбираться, и нашел ваше решение. 🙂
Сэкономили как минимум пол дня 😉
Эта процедура — и была не без греха, так ещё и новых багов поднасыпали.
Кстати, кроме описанного бага, появился и другой, также связанный со ШР. Например, в ШР у вас ставка «месячная», например, 20К руб., а у сотров оклад по часам, то при перемещении и т.п. получите «начать ‘Оклад по дням'».
см. процедуру ДобавитьОбъединенияВЗапросПолученияДействийСНачислениями, вызываемую из ПолучитьТаблицуДействийСНачислениями.
О, спасибо, поковыряю…
(3) Ага, я у себя полностью убрал всё, что они добавили в процедуру «ДобавитьОбъединенияВЗапросПолученияДействийСНачислениями» в 41 релизе (сделал, как было в 40.3). И ещё задолго до этого кучу изменений внёс в «ПолучитьТаблицуДействийСНачислениями», чтобы надбавки из шатного не переносились в кадровое перемещение и приём на работу (они и так попадут в начисления сотра, а потом индивидуально их менять замучаешься). Проще в штатном заменить (на всю должность во всём подразделении).
Спасибо! Поправим.
Ой,молодцы. Если будет время и желание проверьте еще формирование СЗВ для эл.сварщика(27-2 232000-17956 это особые условия труда) которого переместили 01/06/2011 на график 2, а в ШР- для этой должности график 1. Ну не формирует вредность пока в перемещении не поставишь график 1.
Спасибо, добрый человек! Как раз попали на эти грабли…
еще хочу добавить:
было бы здорово, если бы Вы приложили полностью текст исправленной процедуры.
Чтобы благодарным последователям не искать эти соединения по неравенсту и равенству.
Спасибо пригодилась данное решение..
(9) mikhailovaew, Она ОЧЕНЬ огромная…
Могу номера строк типового модуля написать:
1108-1123
1154-1168
1380-1385
тоже столкнулась с этой проблемой, потому что дописывала функцианал, чтобы автоматически выбирался разряд из штатного расписания… после обновления все пришлось переписывать…. бороться с NULL…
(11) да мне-то уже не надо, все найдено и поправлено, я за других переживаю 🙂
а архив текстового файла с процедурой значительно бы сэкономил время ))
спасибо автору и (3)
спасибо, сэкономила время
Спасибо огромное.
Спасибо огромное, тоже уже столкнулись с этим глюком, и сразу нашли ваше решение
Спасибо за экономию времени
Вышел новый релиз, а проблема подстановки «не того» вида расчета из штатного расписания осталась. Это разве так и должно быть? =(
Некоторые глюки годами тянутся… Увы…
(20) Ну просто в 42ом релизе написано «Исправлена ошибка 10092419: При заполнении начислений в документе «Кадровое перемещение организаций» иногда возникают ошибки». Вот и боюсь, что все, что осталось — это не ошибка, а так и должно быть по их мнению =(
Правил Комплексную автоматизацию 1.1.15.1 по данному алгоритму — не помогло.
Разбираться в запросе некогда и я не могу их настолько легко анализировать.
В комплексной возможно ещё какие-то регистры тянутся, там же всё немного сложнее…
К сожалению в данный момент с ней не работаю, а просто так смотреть некогда ))))
Спасибо, очень помогло ) У нас три базы УПП 1.3.19.2
Спасибо огромное!
уже дня 3 бился над этой проблемой
Оказалось все почти тривиально)