Ну да,  основная причина это  внутренние отчёты,  ну и сложившаяся технология работы.

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

Затем  в ОТИЗе  куча своих отчётов по распределению зарплаты.

Ну и потом,  перевыдавать отчёты по зарплате 10-летней давности  - это вероятность меньше 1%.

Да и добавление нового вида для текущей работы тоже вещь непростая,  т.к. видов НУ уже итак много. 

Эта таблица, собственно и делается, чтобы решить проблему 100-й строки.

Есть некий вид, достигший порога 100, у некоторых сотрудников.

Работать с незакрываемым видом, т.е. с датой конца = 01.01.2050, нежелательно.

Вводить новый вид (дублёр) тоже нежелательно,  но допустимо, если на этот вид-дублёр перенести суммыы за 

предыдущие года, с одновременным удалением строк основного вида за те же года.

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

а надо будет сдавать отчёты годовые, как общегосударственные так и ведомственные.

Вот и решили всё-таки создать вид-дублёр но перекодировку делать за конкретный год,  т.е. в древних

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

Задача таблицы заключается в следующем:

- принять суммы, допустим за 2010 год,  по основному виду (с расширением);  

- произвести разноску этих сумм на вид-дублёр (с тем же самым расширением, в тот же 2010);

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

Т.е. - краткий ответ такой  - добавить вид и разнести сумму.

Спасибо!

На каком этапе сложность?   ххх3 не дает рассчитать?

- Рассчитать даёт,  но как первичный,  т.е. выделяет 3 дня за счёт прредприятия.

А если попробовать в рассчитанных БЛ изменить номер ххх2 на ххх1?

- Сделали немного по другому - рассчитали фиктивный БЛ с № ххх1,

  после чего  № ххх3 уже просчитался как продолжение.  

  Только приходится удалять суммы, появившиеся по  № ххх1,  и чистить табель.

Вообще год назад была подобная ситуация,  но работник оказался более настойчивый и 

добился в больнице чтобы в ЭЛН-продолжении проставили  нормальный № первичного БЛ.

Сейчас же в больнице утверждают " вот все другие программы позволяют расчётчикам менять № первичного БЛ

и только ваша не позволяет..."

Получается такая статистика по вопросу:

На предприятии,  где  УсловияИсчисл-НЕТ  и  РазмерСтавки_0.875   --  версия  614

На моём ПК,         где УсловияИсчисл-51      и  РазмерСтавки_1 --  была версия  613

На моём ПК,  (после обновления до версии 614.1)   УсловияИсчисл-51 и РазмерСтавки_0.875

Я правильно понимаю,  что предприятию надо просто обновиться  до версии 614.1  и вопрос снимется?

Спасибо.   Можно закрывать тему.

В КЧ сотрудника в старом интерфейсе  в поле "Код документа" стоит "21".

В 

Настройка -> 6. Общие настройки системы -> 5. Специальные настройки системы. -> Код удостоверения личности по умолчанию

Стояла "1".

Получается, что значение поля КЧ "Код документа"  не видимо  для поля  "Документ, удостоверяющий личность"

нового интерфейса.

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

по примеру выгрузки из стандартной КЧ?

Спасибо Игорь, именно так и сделали уже.

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

Спасибо всем специалистам.

Тему можно закрыть. 

Оказалось,  что если ЭЛН-продолжение вводить не в режиме "Новый"  а в режиме "Продолжение",

то данные по нарушению из первичного БЛ попадают в ЭЛН.

Тему можно закрывать.

Спасибо.

Спасибо!