Пропадающие накопители

Немного истории:

Первый раз я эту проблему встретил в 1996 году в приснопамятной Scala 3.15. Тогда не было Benjamin, я довел это до Сергея Шведова (тогда руководитель Payroll Centre, то есть разработчика модуля Алексея Белова, консультантов и Payroll Bureau в лице Ирины Петренко, — и все сидели в одной комнате). Леша долго чистил (со щедрым применением ненормативной лексики, к чему Ира вынужденно была терпима) первых разработчиков и говорил, что ошибку устойчиво не воспроизвести.

В 2002 году в Светогорске (3500 сотрудников) проблема встала крайне остро. Удалось записать на CD базу данных с воспризводимой (!!!) ошибкой. Других деталей без согласия этого клиента пока не привожу. R&D утверждал, что в последних версиях 5.1 ошибка исправлена.
НО… (читай выше).

У Vome я настраивал модуль Payroll и только после большого давления (в том числе Фроловой) сделал отпуска будущих периодов через периодические накопители, так как так и не получил подтверждения, что проблема решена.

Теперь по-существу:

Пропадают накопители примерно у 0.2% (+1%-0.2%) сотруднико-месяцев, для 1000 сотрудников это до 10 человек в месяц, в среднем примерно 2 человека (если не так — скажите). Как правило это сотрудники, у которых расчитывались больничный лист или отпуск. Особо грешили на команду U10 и U11, но у вас я ее поубирал (проверьте).

За неимением лучшего Шарапов советует восстановить накопители. Это действительно помогает, но только если это удается сделать.

Операция состоит в выполнении двух действий из
Зарплата\Прочие функции\Операции с периодическими накопителями: 1. Удаление периодических накопителей. 2. Обновление периодических накопителей. Именно строго в таком порядке, для всех ТЗ и всех накопителей и строго для одного и того же периода (обычно последний месяц или год). Каждая из этих операций выполняется по моей оценке в квадратичной зависимости от числа человеко-месяцев статистики и рано или поздно (со второго года и второй тысячи человек) становится проблематичной по времени и по памяти. для 2500 человек и 3-х лет не хватило ночи и 2 гигабайт диска (она не освобождает память, а только увеличивает, предположительно для сортировки). И еще на закуску: каждая из этих двух операций выполняется в два этапа, равных по времени, и на первом этапе нет никакой трассировки — просто кажется, что программа зависла. Кстати время выполнения мало зависит от выборки: хоть один месяц, хоть все, хоть один сотрудник, хоть все, — максимум выигрыша во времени: в 2 раза.

Как найти, у кого они пропали.

Отчет из модуля это не покажет, так как ошибка в РА34, а отчеты его не используют. Открывая РА34 другими средствами нужно иметь ввиду, что искать надо не ноль, а отсутствие записей с этой датой у какого-либо неуволенного сотрудника. Это благодаря тому факту, что при отсутствии ошибки хоть какой-то накопитель, да присутствует (заработок для среднего, рабочее время и т.п.).

Как исправить.

1. В тестовой компании открыть модуль Payroll и перенести туда настройку (особенно файл РА03 должен быть последней версии).
2. Передать ошибочные лицевые счета из основной компании в эту тестовую (в компании-экспортере: Зарплата\Прочие функции\Копирование/перемещение сотрудников\перемещение сотрудников).
3. Провести в тестовой компании восстановление периодических накопителей.
4. Вернуть лицевые счета в основную компанию.

И да поможет вам Бог.