Проблема расчета Оклада сотрудника (+)
0 (0)
Проблема расчета Оклада сотрудника (+) ( AlexD 11.11.2004 12:27 )5(1)Сконвертировал данные 5.0 -> 5.1.093. Конвертирование прошло нормально, но возникла проблема по одному из сотрудников - независимо от алгоритма расчета (4-"Оклад", 5-"По окладу за фактически отработано") система почему-то берет к расчету неправильную величину оклада сотрудника. В лицевой карточке - оклад верный, в карточке сотрудника в п.с."Кадры" также правильный. Функции, получения оклада сотрудника за текущий период при вызове из макроса по данному сотруднику также вовзращают правильное значение, а вот расчет по встроенным алгоритмам ведется по неправильному окладу (такая величина действовала в сентябре, а расчет пытаюсь произвести за ноябрь). Подскажите - может быть у кого нибудь были подобные проблемы, или сообщите, кто знает, алгоритм работы встроенных алгоритмов 4, 5 - как они оценивают оклад сотрудника. Заранее признателен за все ответы.
>> Ответить- Проблема расчета Оклада сотрудника (+) ( Рябцева Светлана 11.11.2004 17:33 )5(1)Ситуация очень странная.
1. Для начала проверьте в исходном данном по окладу: в графе «Процент» ничего не проставлено?
2. А данных по изменению оклада (по Ctrl-F6) у Вас нет? Посмотрите через RSL в базе lshtflw.dbt, не заполнены ли данные по новому окладу, дням/часам по новому окладу, день вступления изменений в силу по окладу (поля NewSalary, NewDayF, DayNewSalary)?
А алгоритмы работы встроенных алгоритмов 4, 5 описаны в технологическом руководстве по п/с «Зарплата» в приложении 1.
>> Ответить- Ответы (+) ( AlexD 11.11.2004 18:01 )5(1)1. Проценты == 0.00
2.По Ctrl-F6 - нет никаких данных по новому окладу - старый оклад указан правильно - 2300.00 часы и дги тоже. При просмотре RSL-ем поля NewSalary, NewDayF, DayNewSalary - нулевые
Судя по описанию, значение оклада для расчета берется равным полю sallary таблицы lshtflw.dbt - там установлено 2300.00. Однако система настойчиво рассчитывает 2100.00 при установленном алгоритме Оклад. Просмотрел еще поля sum и percent таблицы method - везде нули. Вобщем - чудеса.
>> Ответить- Пересоздайте lshtflw.dbt ( Рябцева Светлана 11.11.2004 18:47 )5(1)Попробуйте сохранить lshtflw.dbt под др. именем, пересоздать его по словарю. После этого выгрузить содержимое Btrieve-файла в текстовый файл (BUTIL -RECOVER) и загрузить информацию из текстового файла в пустую структуру (BUTIL -LOAD).
>> Ответить- Сделал (+) ( AlexD 12.11.2004 10:17 )5(1)Пересоздавал файлы и по словарю и при помощи BUTIL -CLONE. Закачивал туда информацию и с помощью BUTIl -COPY, и c помощью BUTIL -LOAD (RECOVER). Эффект нулевой - все остается по-старому. Светлана, подскажите, пожалуйста, какие таблицы, кроме lsthflw, reznach участвуют в расчетах по алгоритму 4?. Используется ли в момент расчета позиционирование (поиск записи) в lshtflw и по какому ключу? Кстатит, попробовал закрыть расчетный период - закрытие прошло нормально. В новом периоде при расчете по этому сотруднику система увеличила ему результат расчета по алгоритму 4 на 100 рублей, т.е. - в lshtflw указан оклад 2300, при расчете за ноябрь - резудьтат расчета - 2100, при расчете за декабрь - 2200.
>> Ответить - В продолжение темы (+) ( AlexD 12.11.2004 11:07 )5(1)Написал макрос расчета следующего содержания:
import ZpProc_Info, ZpProc_Calc; sv_total (sv_sal ());
Все рассчиталось верно.
Усложнил - постарался повторить алгоритм, описанный в руководстве:
import ZpProc_Info, ZpProc_Calc;
var perc = sv_percpan ();
if (perc <= 0.)
perc = 100.;
end;
sv_total( ( (sv_newsal()*sv_newdayfact ()+sv_sal*(sv_daygr ()-sv_newdayfact))/sv_daygr)*(perc/100)+sv_sumpan ());
- и опять все верно;
Сейчас буду пробовать написать макрос, который обращается непосредственно к таблицам и их полям,
вот для этого мне и нужен более подробный алгоритм.
>> Ответить- Ответы ( Рябцева Светлана 12.11.2004 13:25 )5(1)Участвуют в расчетах по алгоритму 4 таблицы lshtflw.dbt, edit_lsf.dbt, method.dbt, reznach.dbt, paylist.dbt, plancalc.dbt и еще десяток вспомогательных файлов.
Поиск записи в lshtflw.dbt идет по 0 ключу Tnumb, DateC.
Конечно, неверно оклад может рассчитываться по разным причинам: например, была корректировка оклада в архивных РП и т.д. Чтобы найти причину, нужна Ваша база.
>> Ответить- Готов выслать Вам таблицы (+) ( AlexD 15.11.2004 10:03 )5(1)Назовите адрес и список таблиц. Спасибо за ответы.
>> Ответить- моя версия (+) ( Alexander 15.11.2004 11:03 )5(1)посмотрите записи по этому сотруднику в edit_lsf.dbt, есть? какие? оклад и дата?
>> Ответить- По данному сотруднику записей в указанной таблице - нет (-) ( AlexD 16.11.2004 09:18 )5(1)Not specified
>> Ответить- Проблема еще не решена? (+) ( Alexander 17.11.2004 17:40 )5(1)любопытная ситуация
Попробую отмести глюки:
А данные для начисления вводились с нуля?
А если поставить у данного начисления фиксированную сумму 0 - расчитает 0
А если произвести изменение оклада (превод сотрудника) на новый (например 10000) - считать будет как?
А Даты верно стоят?
>> Ответить- Проблема так и не решена (+) ( AlexD 18.11.2004 09:34 )5(1)1.Данные для начисления. Производился расчет как сразу после конвертирования данных из 5.0, так и после удаления всех исходных данных в расчетном периоде по данному сотруднику и ввода их руками.
2.Фиксированная сумма - 0. Результат расчета - 0.
3.Изменение оклада. Пробовал менять оклад как из списка лицевых карточек, так и из списка сотрудников (причем в обеих подсистемах "Заработная плата" и "кадровая служба") - эффект - нулевой.
4.Даты.Не могли бы Вы усточнить о каких датах идет речь?
>> Ответить- Предположений все меньше... (+) ( Alexander 19.11.2004 09:15 )5(1)Дата РП, > Сервс - Даты -текущие РП и друие даты -проверьте корректность.
Эту же дату (если ее не менять :-)) видно при вводе начисления - в данных корректировки начисления.
Можно попробовать еще одну вещь -откатить месяц -проверить расчет по этому сотруднику, потом закрыть РП и еще раз расчитать - сделать выводы исходя из итога.
Из какой вообще суммы происходит расчет - это вообще левая сумма или это "старый" оклад сотрудника
>> Ответить- Продолжим...(+) ( AlexD 19.11.2004 11:07 )5(1)Дата РП - верная - 11.2004. Эта же дата отображается и по лицевому счету, и про вводе нового исходного данного для расчета дата проставляется верно.
Вопрос - как откатить месяц?
Такой оклад присутствовал по данному сотруднику в сентябе.
>> Ответить- Cмотрим еще (+) ( Alexander 19.11.2004 11:31 )5(1)пока поддержка, как я понял в недоумении...
1) Во время расчета - в статусной строке мелькает какой-либо архивный месяц? ...может происходит архивный перерасчет за сентябрь? Само расчитанное начисление ТОЧНО за 11 месяц?
Откатить (ессно на тестовой базе) - просто изменить дату РП на -1 месяц, расчитать не помогло - еще откат в сентябрь, еще расчет.. потом постепенно, возвращаемся.
2) Забудем пока про оклад... пробуем изменить фактические дни за 11 месяц - сумма меняется? А если попробовать изменить календарь не изменяя фактич. дни по сотруднику...
Что получаем?
>> Ответить- Забудем про оклад (+) ( AlexD 19.11.2004 12:23 )5(1)В том-то и дело, что я использую встроенный алгоритм - 4 ("Оклад"), а не - 5 ("По окладу за фактически отработано") - в данном случае как я понимаю, от фактических дней ничего не зависит
>> Ответить- дело не в этом (+) ( Alexander 19.11.2004 12:49 )5(1)я удаленно пытаюсь "видеть вашими глазами", чтобы понять что происходит
1) диагноз - берутся данные сентября
2) уточнение - берется оклад сентября
3) вопрос - а другие данные берутся? или другие данные берутся уже из 11 месяца?
4) другие данные -это, например(из основных) дни - дни календаря сентября и дни фактические сентября.
5) и (думаю)неважно каким именно алгоритмом - хоть своим собственным, но корректно написанным.. а простецкий ваш пример - это как раз некорректно написанный алгоритм, не учитывающий все возможные изменения по сотруднику.
>> Ответить
- Явная ошибка обработки оклада на испытательный срок! ( Alexander 29.11.2004 15:13 )5(1)R-style, проблема Вам ясна?
Меня просто убивают такие "детские" ошибки... Когда же коммерческое ПО начнут писать программисты профессионалы, а не зеленые студенты?
AlexD, а Вы то почему затихли - разобрались?
>> Ответить- Действительно у этого сотрудника стоит испытательный срок с установленным окладом (+) ( AlexD 29.11.2004 15:49 )5(1)Александр, спасибо Вам огромное. А замолчал я, потомучто текучка оторвала от решения этой проблемы. Сейчас получил 5.1.104 - буду пробовать переходить на нее. А если не секрет, как Вы догадались об испытательном сроке?
>> Ответить- Ловкость рук и никакого мошенничества (+) ( Alexander 29.11.2004 16:21 )5(1)Вас оторвали дела - глаз у меня не было... и тут сосед (он сейчас занимается УХДБ) обращается почти с той же проблемой - у сотрудника изменили оклад, а считается по старому - появились собственные глаза, что несомненно дало возможность докопаться до истины! Пооперировал с днями, календарем.. стали ручками rsl править оклады в базах - подумал о базе перемещений - хистори - там 2 поля с окладом - все просто.
Решение - меняем дату действия испытательного срока на более позднюю - для нас на предыдущие месяц (либо вообще эти данные убираем)
Я Вам практически гарантирую данную ошибку в 104 сборке.. и еще 10 новых сверху ;)... но и нам придется переходить тоже.
>> Ответить- А я пока работаю на 5.0 - там таких проблем - нет (+) ( AlexD 29.11.2004 16:43 )5(1)На 5.0 работаем давно (с "зарплатой" уже больше 7 лет) - это, наверное, и подвело.
Первое на что грешишь, после конвертации данных - что-то не так сконвертировалось. Вот я и занимался, в основном, проверкой корректности переноса данных. А оказывается алгоритм расчета, приведенный в документации, не соответсвует тому, как в действительности этот алгоритм работает. Еще раз - спасибо.
>> Ответить- Да -не повезло Вам, что переходите с более-менее отлаженной 5.0 версии. ( Alexander 29.11.2004 17:20 )5(1)Мы вот тоже с 1 января (год назад) перешли и неоднократно об этом жалели.
Кстати, если есть доступ к айсу - можете почитать там доступные темы, чтобы заранее обойти возможные грабли.
>> Ответить- Так ведь R-Style официально заявил о прекращении поддержки модулей УХДБ в 5.0 (-) ( AlexD 30.11.2004 09:56 )5(1)Not specified
>> Ответить- Данная ошибка будет исправлена в одном из ближайших патчей 5.10. ( Рябцева Светлана 30.11.2004 19:04 )5(1)Not specified
>> Ответить
