декрет (отпуск по уходу до 3-х лет)

> не скажет
но и не изменит состояние. теперь чтобы поменять состояние надо все отменить (второй отпуск и декрет), а потом правильно все провести.
или менять поведение реквизита  в справочнике.

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

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

вот история через print screen (см.вложение)... сойдет так?))))

Я плачу уже 2-ой день подряд...мне же надо индивидуальные сведения сдавать(((((((((( эта программа меня просто с ума сводит!

заполнение реквизита некорректно, но может помочь перепроведение 1-го отпуска с датой по "16.11.11". Это сделать надо будет обязательно. На крайний случай всегда можно поставить стаж в самом сотруднике.

А если попробовать изменить "состояние физлица" на "временно не работает"на конкретную дату 07.06.12 с помощью стандартной обработки Uchoice.ert ?
Только сначала в конфигураторе в справочнике Сотрудники у реквизита СостояниеФизлица установить возможность ручного изменения.
На демобазе попробовал - вроде получилось

Я бы поправил если бы вы мне дали порулить своим компьютером немного.
Напишите что нибудь личным сообщением я в ответ вышлю "инструкцию" о том как бы вы могли дать мне возможность доступа.

как поправляли бы?

Суть проблемы вот в чем.
Когда в программу заносят документ-отклонение и проводят его, алгоритм в реквизит СостояниеФизлица пишет сразу два значения.
Первое = регистрация начала события (например, запись в историю значения "Временно не работает").
Второе = регистрация его окончания и восстановление состояния физлица, которое было в системе до регистрации этого документа-отклонения, причем это делается сразу же, то есть, проводя документ "Отпуск по уходу за ребенком" с 27.08.2009 г. по 06.06.2012 г., мы в истории получим такие записи:
27.08.2009 Временно не работает
07.06.2012 Сотрудник по основному месту работы

Смысловая ошибка тут во второй части алгоритма. В принципе написано все верно и работало бы все корректно, но только в том случае если на этот же диапазон не попадает ни один другой документ-отклонение. Такую ситуацию просто не учли разработчики. Но ситуация достаточно редкая, я с ней встречаюсь лишь четвертый раз. Всегда это связано с уходом в отпуск по уходу за вторым ребенком во время действия отпуска по уходу за первым ребенком. Подобные ситуации уже рассматривались и на этом форуме, например вот: http://www.buh.ru/forum/thread.jsp?id=517022&sortt=m.left_ns
Причем я там дал неверную рекомендацию по попытке решения проблемы с помощью документа "Изменение условий оплаты отпуска по уходу". Если посмотреть его алгоритм, то можно увидеть, что он затрагивает лишь сведения, связанные с параметрами начислений, но никак не затрагивает реквизит СостояниеФизлица, значения которого являются некорректными.

Вот как в идеале должна была вести себя программа при вводе в нее второго Отпуска по уходу за ребенком с 05.04.2012 г. по 26.01.2015 г.?
Она должна была не просто вписать в систему два значения по аналогии с вышеуказанными. Нужно было чтобы система увидела что дата 05.04.2012 г. попадает в период действия первого отклонения (с 27.08.2009 г. по 06.06.2012 г.), зачистить значение, установленное на 07.06.2012 г., так как оно утрачивается в смысле корректности. Но! Значение это не просто вписано в историю реквизита. Оно вписано при проведении документа, да еще и иного нежели проводимый (регистратором был первый документ, зачистка должна быть выполнена вторым документом). Движок платформы не дает возможность как то воздействовать на такие значения кроме как непосредственно в модулях документов-регистраторов. Все еще усложняется механизмом отмены проведения (при отмене проведения второго документа, необходимо воскресить удаленное значение, порожденное изначально первым документом). Поэтому, теоретически, в конфигурации "Зарплата и кадры" & "Комплексная конфигурация" требуется глобальная переработка, которая в систему добавит некий справочник, в котором будет реквизит "действие по установке периодического значения отменено документом таким то" + переработка всех алгоритмов, которые как то работают с реквизитом СостояниеФизЛица. Но поскольку это довольно большая задача и сравнительно редкая ситуация, да еще и с учетом того, что версия 8 считается приоритетной, никто это делать не будет. Поэтому я бы для решения этой конкретной проблемы сделал (и ранее делал) все просто. Я бы убрал лишнюю запись о том, что с 07.06.2012 г. нужно считать статусом "Сотрудник по основному месту работы". Манипулированием стандартными механизмами платформы этого не достичь никак, поэтому я бы убрал значение напрямую из таблицы базы данных. Это сверхредкая ситуация, когда я бы действительно выбрал именно прямое воздействие на таблицы базы. Это совсем не руководство к пременению и повсеместно так делать ни в коем случае нельзя
Еще журнал расчетов бы почистил, чтобы записей, которые там появились из за некорректного значения, не было.