1С 8.2 ЗУП КОРП (2.5.66.2)
Нужен совет. Ситуация в следующем. После переноса данных из 1С 7.7 ЗиК сформировался регистр сведений ПлановыеНачисленияРаботниковОрганизаций (ПНРО). Далее попытался заполнить Штатное расписание (регистр сведений) штатной кнопкой на определенную дату на форме регистра. Заполнение было некорректно. А в чем именно: Если в ПНРО присутствует не пустая ДатаЗавершения но при этом ВидРасчетаЗавершения Пустой (или Неопределено - т.к. составной тип), то в Штатном расписании появляются строки с незаполненными мин. и макс. размерами ставок и пустым ВидомТарифнойСтавки.
Далее делается вывод, что ПНРО непрально заполнился после переноса. Стал копать. Для эксперемента провел по одному из сотрудников Кадровое перемещение с указанием даты начала и конца. К моему удивлению ПНРО заполнился также как и после переноса из 7-ки, т.е. дата завершения есть а вид расчета пустой.

Итак стою на перепутье: или Менять ПНРО (по другому заполнить) или же переделать процедуру заполнения Штатного расписания.
Что из 2-х лучше всего выбрать?

ПНРО не трогать.
"переделать процедуру заполнения Штатного расписания"

И вообще - может быстрее и надежнее руками надбавки проверить в ШР ?

2к сотрудников). Тоже склоняюся к ошибке 1С-овцев. Такие моменты к сожалению есть и в других местах. Необходимо быть осторожным(.

(3) это не совсем ошибка - недоделанная фича.
а если фича не имеет описания, то следует признавать ее багом.

Процедура работает более штатно, чем заполнение плановых начислений. Но конкретный кусочек процедуры, который обрабатывает дату завершения, он [кусочек] либо лишний совсем, либо некорретный.

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

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

(5) В расчетах такое поле не использовалось. Хотя, если такое в структуре сидит, то кто-нибудь когда-то где-то при обновлении может его воткнуть... Проблема же в том, что регистр ПНРО стандартно имеет первое поле "период". Это же дополнительное поле воткнули, чтоб... фиг его знает зачем воткнули... Прекращение действия одного ПНРО можно ввести второй записью на том же составе/значениях измерений с очищенным значением ресурса. Но взамен этого просто решили экономить записи. А в результате наплодили усложненные и неоднозначные обработки значений из этого поля. И в расчетах обходятся без анализа по этому полю.