Здравствуйте.

Вышла забавная ситуация:
есть куча видов оплаты в 14ИТ, которые в P0014 деляет период на полупериоды. Получается 5 полупериодов.
Есть оклад 10 000р.

При полной отработке факт=план после умножения оклада на коэф. сокращения выходит оклад = 10 000, 01. Как с этой копейкой цивилизованно бороться?

Проверьте, что при расчете коэффициентов Вы пользуетесь константой KGENAU и что она достаточно велика (ну хотя бы не меньше 1000).

Ага, умножить перед делением оклад на 1000, а после деления разделить.

Это уже результат обработки с константой KGENAU = 100 000. Сокращение идет через стандартные /80* коэф, на базе часов.

Да, есть копейки при наличии достаточно большого количества разбиений /80х.

Как вариант доработать правило, в котором идет применение коэффициентов на проверку: если значения типа G из PARTA нулевые, а значения G и T из PARTT одинаковы в части *DIVI, то не применять коэффициенты к окладу.

Мможно, пожалуйста, чуть подробнее? Немного не понял логику :(

Подниму тему.
Столкнулся с аналогичной проблемой, GENAU 1000000 больше не получается ))), а разница в копейку есть. Кто как борется с проблемой?

Попробуете описанное решение выше. Смысл в том, что мы проверяем, что отработка была полной + то, что график не менялся. При этих условиях коэффициент сокращения можно не применять. После создания /8хх идет правило применения этих коэффициентов.вот в нем проверяйте описанное условие

Помоем это очень частное решение, т.к. разбиение может возникнуть и из-за смены МВЗ или из-за косвеной оценки (например исполнилось 30 лет и имеем северную надбавку), если в таких случаях не разбивать оклад на части то получаем другие рода погрешности или пренебрежения.

Если цель получить сумму оклада без погрешности, то можно проверять, что месяц отработан полностью и в последнем полупериоде делать корректировку погрешности.
А если цель подогнать расчет к параллельному расчету в другой системе, тогда лучше придумать возможность прогрузки дельт расчета.

Есть очень простой алгоритм хорошего округления.
Хранение погрешности на каждой итерации, для следующей итерации.
есть у нас оклад 100р.
1. Берем нужный /8* (в нем уже есть genau) умножаем на оклад и прибавляем значение Q (далее будет понятно зачем) и запоминаем .
2. Берем значение из п.1 делим на genau запоминаем для дальнейшего расчета.
3. Берем полученное значение в п.2 умножаем на genau и отнимаем значение п.1 и запоминаем в Q для следующей итерации.
И так для каждого вида оплаты.

т.е. Q - это погрешность которая сформировалась на предыдущей итерации.
Как реализовать, зависит от вашей фантазии. Результат гарантирую.

Спасибо коллеги! В моём случае у человека были переводы на разные графики, и проблема именно в округлении.

--------
Для каждого вида оплат? Т.е. для каждого сплитованного куска оклада (или /8*) ?
А если Q останется после последнего сплита? И как алгоритм отработает если оклад менялся в течение месяца?

Q для каждого нового ВО = 0.
Как реализовать зависит от вашей фантазии.
Вы попробуйте на бумаге или excel. У вас все получиться .
genau должен быть не меньше 10000 (этой цифры достаточно).

К сожалению не совсем понятен алгоритм (( Можно пример расчёта или правила. Или пояснить по подробнее.