Глюк в ЗУП 2.5.41.3 — модуль "ЗаполнениеДокументовЗК"

Исправление глюка в ЗУП 2.5.41.3 (общий модуль "ЗаполнениеДокументовЗК")

Заметил, что в документе «Кадровое перемещение» при подборе сотрудников не всегда во вкладку

«Начисления» попадают все начисления сотрудника. Начал ковырять сначала пользовательские настройки

и последовательность заполнения всех документов, параметров учёта и т.д…

Выяснил, что эта фигня наблюдается только при наличии штатного расписания Smile

Причём, если штатное расписание по должности нужного сотрудника заполнено ПОСЛЕ даты документа

«Кадровое перемещение организации», всё работает отлично. Если же штатное расписание заполнено в

тот же день или ранее, начинаются глюки. Стало интересно… оказалось, что не только в этом документе

наблюдается данный глюк.

После этого пошли ковыряния в конфигураторе… Нашёл )))) Оказывается в одни и те же поля в разных кусках запроса

запихивается то 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/>

| И НачисленияСтаройПозицииСрезПоследних.Сотрудник = НачисленияСотрудника.Сотрудник

|

|ОБЪЕДИНИТЬ

 

Вуаля! Всё работает… Ну, соответственно, где есть неравенство «<>», тоже добавляем…

25 Comments

  1. Voody

    Спасибо.

    Тоже заметил это через день после обновления. Вот только сел разбираться, и нашел ваше решение. 🙂

    Reply
  2. VitaliyTokarev

    Сэкономили как минимум пол дня 😉

    Reply
  3. Gesperid

    Эта процедура — и была не без греха, так ещё и новых багов поднасыпали.

    Кстати, кроме описанного бага, появился и другой, также связанный со ШР. Например, в ШР у вас ставка «месячная», например, 20К руб., а у сотров оклад по часам, то при перемещении и т.п. получите «начать ‘Оклад по дням'».

    см. процедуру ДобавитьОбъединенияВЗапросПолученияДействийСНачислениями, вызываемую из ПолучитьТаблицуДействийСНачислениями.

    Reply
  4. VitaliyTokarev

    О, спасибо, поковыряю…

    Reply
  5. BoneD

    (3) Ага, я у себя полностью убрал всё, что они добавили в процедуру «ДобавитьОбъединенияВЗапросПолученияДействийСНачислениями» в 41 релизе (сделал, как было в 40.3). И ещё задолго до этого кучу изменений внёс в «ПолучитьТаблицуДействийСНачислениями», чтобы надбавки из шатного не переносились в кадровое перемещение и приём на работу (они и так попадут в начисления сотра, а потом индивидуально их менять замучаешься). Проще в штатном заменить (на всю должность во всём подразделении).

    Reply
  6. silver-fox87

    Спасибо! Поправим.

    Reply
  7. Lukich66

    Ой,молодцы. Если будет время и желание проверьте еще формирование СЗВ для эл.сварщика(27-2 232000-17956 это особые условия труда) которого переместили 01/06/2011 на график 2, а в ШР- для этой должности график 1. Ну не формирует вредность пока в перемещении не поставишь график 1.

    Reply
  8. mikhailovaew

    Спасибо, добрый человек! Как раз попали на эти грабли…

    Reply
  9. mikhailovaew

    еще хочу добавить:

    было бы здорово, если бы Вы приложили полностью текст исправленной процедуры.

    Чтобы благодарным последователям не искать эти соединения по неравенсту и равенству.

    Reply
  10. nitr02k

    Спасибо пригодилась данное решение..

    Reply
  11. VitaliyTokarev

    (9) mikhailovaew, Она ОЧЕНЬ огромная…

    Могу номера строк типового модуля написать:

    1108-1123

    1154-1168

    1380-1385

    Reply
  12. Beta

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

    Reply
  13. mikhailovaew

    (11) да мне-то уже не надо, все найдено и поправлено, я за других переживаю 🙂

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

    Reply
  14. prog-eg

    спасибо автору и (3)

    Reply
  15. Галко

    спасибо, сэкономила время

    Reply
  16. Lyuda11

    Спасибо огромное.

    Reply
  17. ГердаКай

    Спасибо огромное, тоже уже столкнулись с этим глюком, и сразу нашли ваше решение

    Reply
  18. vec435

    Спасибо за экономию времени

    Reply
  19. Risa

    (3) Вышел новый релиз, а проблема подстановки «не того» вида расчета из штатного расписания осталась. Это разве так и должно быть? =(

    Reply
  20. VitaliyTokarev

    Некоторые глюки годами тянутся… Увы…

    Reply
  21. Risa

    (20) Ну просто в 42ом релизе написано «Исправлена ошибка 10092419: При заполнении начислений в документе «Кадровое перемещение организаций» иногда возникают ошибки». Вот и боюсь, что все, что осталось — это не ошибка, а так и должно быть по их мнению =(

    Reply
  22. serega_sun

    Правил Комплексную автоматизацию 1.1.15.1 по данному алгоритму — не помогло.

    Разбираться в запросе некогда и я не могу их настолько легко анализировать.

    Reply
  23. VitaliyTokarev

    В комплексной возможно ещё какие-то регистры тянутся, там же всё немного сложнее…

    К сожалению в данный момент с ней не работаю, а просто так смотреть некогда ))))

    Reply
  24. Elis-Velis

    Спасибо, очень помогло ) У нас три базы УПП 1.3.19.2

    Reply
  25. Den_Zenit

    Спасибо огромное!

    уже дня 3 бился над этой проблемой

    Оказалось все почти тривиально)

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *