Наверняка на многих проектах используется суммированный учет времени. Мне вот тоже понадобилось. Несколько вопросов общих:

1. Какие группировки сотрудников использовались? Группы? Категории? СтатусУправленияВременнымиДанными? Еще что-то?
Т.е. как сотрудников отличать? И нужно ли вообще отличать "суммированных" сотрудников от остальных?
Я собрался сделать разные категории, но задумался правильно или нет? Есть же категории Окладных сотрудников, есть для Тарифа. Вроде эти слова относятся к формам оплаты труда, а суммированный учет - это форма учета рабочего времени, а это из другой песни.

2. Какой статус управления временными данными у вас для суммированных сотрудников? (Обычно 0 или 9 а что тут будет?)

3 В какие отчеты "суммированные" сотрудники должны попадать отдельной строкой? Рець о "государственных отчетах" для налоговой и статистических служб.

4 Что в русском аддоне есть про суммированный учет? Что нибудь есть в схеме расчета? Или переработки/сверхурочные самостоятельно нужно отслеживать и оплачивать.

5 Ну и общий вопрос. И как? Работает?

восспадя, сколько вопросов =)
кратко отвечу
используется, да
категориями отличали
отличать нужно обязательно, их - же считать иначе
9 у нас статус, т.е. с оценкой времени, дальше уже в схеме различается
в аддоне что-то есть(4.7+best practices) например рачет всего в часах но переработок например нет - надо самим
период учета ставится групе/категории в T7RU53

что именно работает, кажется твой постинг надо минимум на 5 разбить =))))

"период учета ставится групе/категории в T7RU53 "

А для каких целей? Только для VAKEYPRGSC?

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

да

Лично мне на категориях не нравится.
Проблемы начинаются при переходе с суммированного на несуммированный и обратно. Тогда либо абап, либо лишние записи в ИТ0001.

В аддоне есть только места для расчета средних.
Переработки обычно делаются в схеме оценке времени, а потому - это проектная работа. Русская разработка не может править схему оценки времени.

1. Да, для суммированных - свои категории.
2. Как обычно, есть оценка времени - 9, нет оценки - 0.
3. Что-то я таких сходу не припомню
5. Работает вполне.


Какой еще способ разрулить ситуацию?

См. выше - класс графика на период, например.
На одном очень большом проекте использовали статус учета временных данных...
В любом случае - желательно использовать объект PT.
ИМХО.

Т.е. переименовывали стандартные статусы, чтобы проверка нормально отрабатывала или check дописывали?

Переименовывали

Стоит задача внедрить суммированный учет.
Что-то не очень понял идею с использованием класса оценки для периодических графиков V_551C_B?

Как говорила Алиса, для каждого учетного периода нужно графику присваивать разный класс. Но когда попытался скопировать график и проставить другой класс - система выдала сообщение, что запись с таким ключом уже есть.

Неужели, в этом случае, для каждого учетного периода, а их 4 нужно создавать свой график и дла каждого графика проставлять разные классы оценки (соответствующие учет. пер.) в таблице V_551C_B?

Если кто реализовывал, можно чуть поподробнее, если не сложно!

Добрый день!

Коллеги не подскажите, как в схеме расчета зарплаты считать сотруднику на суммированном учете оклад?
На сколько я понимаю он должен считаться следующим образом:
оклад делится на кол-во часов по произв. графику, подлежащему отработке и умножается на кол-во фактически отработанных часов.

Но откуда у сотрудника брать данные производственно графика, если в 7ИТ у него стоит свой?
Это что нужно писать свою операцию?

И что делать если сотрудник перевелся в середине месяца с суммированного учета на несуммированный.

Сделать свою PT-операцию на основе RUGAB'a
Переход легко отрабатывается на статусах учета временных данных, VARST'ом

Proforg, так это же используется в оценке времени!
А в расчете необходимо иметь данные производственного календаря, но ведь еще раз повторюсь у таких сотрудников в 7ИТ свой нормативный график!
Ах да и еще как я понимаю, для суммированного учета коэффициенты сокращения не используются, или я ошибаюсь?
Может кто рассказать как считается в схеме расчета з/п оклад по сотрудникам на суммированном учете.

Буду очень признателен!!!

Я же пишу, что надо написать PT-операцию на основе зарплатной RUGAB, которая будет лезть в t7ru80s и оттуда брать нужные значения


А как угодно. Оклад и суммированный учет = всякие извращения. Т.е. можно считать по личному графику, можно по нормативному, там еще всякие кундштюки с праздниками в норме/ вне нормы могут быть