Отправлено: napan от Июнь 22, 2010, 04:07:43 pm
Вложения:
-06.dt
Отправлено: Andrey-ka от Июнь 22, 2010, 10:03:38 pm
Отправлено: napan от Июнь 24, 2010, 02:31:48 pm
Отправлено: skanny от Июнь 26, 2010, 02:21:06 pm
Отправлено: napan от Июнь 27, 2010, 02:45:49 pm
Отправлено: aworld от Август 05, 2010, 08:14:29 pm
то есть это не часовая ставка как в других задачах и умножать ее на количество часов факт не надо, ИМХО.
Отправлено: napan от Сентябрь 15, 2010, 05:55:20 pm
Quote (aworld)
В тексте задачи написано что СУММА НАЧИСЛЕНИЯ по окладу определяется как нач значение оклада деленное на количество рабочих часов.
то есть это не часовая ставка как в других задачах и умножать ее на количество часов факт не надо, ИМХО.
то есть это не часовая ставка как в других задачах и умножать ее на количество часов факт не надо, ИМХО.
Ага и получается например у него Оклад 3000, то начисляем ему (рабочих часов например 168) 3000 / 168 = 17,86??? Да ну глупость же. Конечно Надо умножать на фактически отработанное время!
Отправлено: ut2k5 от Сентябрь 21, 2010, 01:32:34 pm
могу конечно тупо в лоб проверкой после записи, но мне кажется, что это будет не верно, подозреваю, что есть какие-то спец. механизмы для такого метода, подсобите, плиз...
Отправлено: aworld от Сентябрь 21, 2010, 01:50:04 pm
Отправлено: ut2k5 от Сентябрь 24, 2010, 09:29:54 am
Вложения:
Quest_3_6.dt
Отправлено: SergTH000 от Сентябрь 24, 2010, 01:47:26 pm
Добавлено (24.09.2010, 13:24)
---------------------------------------------
ut2k5,
1.В задаче требование, что данные о командировке могут вводиться задним числом. Т.е. период регистрации сейчас, а период действия раньше. Ты же базу для командировки определяешь по периоду регистрации, это не верно, нужно от периода действия. А период действия ты разбиваешь. Чуть попозже выложу свое решение
Добавлено (24.09.2010, 13:25)
---------------------------------------------
Сказано же разбивать оклад не нужно, а тебя все основные начисления разбиваются
Добавлено (24.09.2010, 13:26)
---------------------------------------------
В начале движения старые не удаляешь)
Добавлено (24.09.2010, 13:35)
---------------------------------------------
Зачем так много полей выбираешь, при расчете основных начислений?
Добавлено (24.09.2010, 13:47)
---------------------------------------------
По-моему условие, что фактический период действия лежит в нужном интервале, нужно задавать в соединении таблиц, а не в конструкции ГДЕ.
Отправлено: ut2k5 от Сентябрь 27, 2010, 07:11:45 pm
1) Движение = Движения.ОсновныеНачисления.Добавить();
2) ... // заполняем движение
3) Движения.Записать();
4) ...// и только теперь анализируем движения в общем модуле, но уже после записи....
так что зачем лишний раз очишать..?
Отправлено: SergTH000 от Сентябрь 27, 2010, 11:55:24 pm
Отправлено: ut2k5 от Сентябрь 29, 2010, 01:38:06 pm
Отправлено: SergTH000 от Сентябрь 29, 2010, 03:28:09 pm
Отправлено: Dinobobrik от Сентябрь 29, 2010, 03:33:03 pm
Отправлено: SergTH000 от Сентябрь 29, 2010, 04:17:19 pm
Отправлено: Dinobobrik от Сентябрь 29, 2010, 10:43:39 pm
а зачем движения передавать в общий модуль?
можно же спокойно в модуле документа "Начисление" это сделать
Отправлено: SergTH000 от Сентябрь 30, 2010, 09:57:41 am
Отправлено: sada от Сентябрь 30, 2010, 10:49:47 am
Вложения:
1Cv8_3_06.dt
Отправлено: ut2k5 от Сентябрь 30, 2010, 11:25:35 am
но зато респект тебе за то, как разбил период коммандировки, в остальном вроде все ок...
ах вот еще, мелочь, но все же, у тебя реквизит документа ПериодРегистрации не выставляется на начало месяца, я конечно понимаю, что вроде и период в регистре будет сам выставляться на начало, но все же это по-моему регламент...
Аааа, вот теперь точно нашел ошибку, у тебя записи сторно без минуса рисуются 
это уж явно ошибка
Отправлено: sada от Сентябрь 30, 2010, 01:43:14 pm
Quote (ut2k5)
почему у тебя оклад является базовым для оклада?
сам не пойму , явно не к чему
1.5 месяца назад эту задачу делал
Quote (ut2k5)
а вот командировка наоборот должна быть базовой для самой себя, потому как в задании явно указано "всех начислений за предыдущий период", а вдруг он весь прошлый период был в командировке, соответствено текущую ком-ку нужно считать иходя из предыдущей... но это имхо (мое понимание задачи),
- согласен!
Quote (ut2k5)
третье: зачем ведущие назначены у некоторых видов расчетов, сказано же "механизм перерасчетов использовать не надо"?
- это не критично
Quote (ut2k5)
в общем модуле расчета у тебя каждый запрос отдельно расчитывает каждый вид расчета, на мой взгляд должно быть два (основные и дополнительные), даже не надо вводить приоритет так как командировка танцует не от текущего оклада....
- приоритет тут не нужен, в моем решении его тоже нет, а расчитывать для всех сотрудников значение общей базы за прошлый месяц , даже если там нет командировок, а для командировок вычислять значение оклада, в зависимости от периода ее действия, думаю не самый оптимальный вариант.
Quote (ut2k5)
Аааа, вот теперь точно нашел ошибку, у тебя записи сторно без минуса рисуются это уж явно ошибка
- ок, хорошо хоть что исправляется легко
Отправлено: Dinobobrik от Сентябрь 30, 2010, 08:00:47 pm
В связи с этим у меня вопрос: Почему так обязательно производить расчет на сервере???
Отправлено: SergTH000 от Октябрь 01, 2010, 07:33:16 am
Отправлено: sada от Октябрь 01, 2010, 07:59:09 am
Quote (Dinobobrik)
Почему так обязательно производить расчет на сервере???
Потому что для расчета нужны данные не доступные в тонком и web клиенте
Отправлено: SergTH000 от Октябрь 01, 2010, 09:55:03 am
Отправлено: Dinobobrik от Октябрь 01, 2010, 04:41:26 pm
Отправлено: sada от Октябрь 01, 2010, 05:00:12 pm
Отправлено: Dinobobrik от Октябрь 05, 2010, 12:40:45 pm
Часто алгоритмы расчетов выносят в специальный общий модуль. Это технологически оправдано, поскольку общий модуль можно выполнять на сервере (в клиент-серверных версиях), что в целом ускорит расчет. Также достаточно удобно хранить все алгоритмы расчетов в одном месте, особенно при возникновении необходимости корректировки в процессе работы алгоритмов расчета
После такого ответа мне стали понятны слова диктора на видеокурсе: "В 8.2 модуль документа итак выполняется на сервере, поэтому нет необходимости выносить процедуру расчета в общий модуль"
Это то же самое, что вы мне выше уже сказали, но только в той форме, которая понятна недостаточно компетентному в этих вещах типа меня
Отправлено: baksha_bni от Октябрь 14, 2010, 10:40:14 am
Вложения:
3.06_Baksha_bni.dt
Отправлено: Dinobobrik от Октябрь 21, 2010, 03:34:40 pm
sada, baksha_bni
премия не сторнируется при вводе командировки задним числом.
Подскажите, где можно посмотреть как премию отсторнировать. В таблице дополнений она у меня не подтягивается
Отправлено: sada от Октябрь 21, 2010, 05:51:18 pm
Отправлено: Dinobobrik от Октябрь 21, 2010, 06:50:37 pm
Сторнирование суммы премии - это правильнее выразиться: перерасчет премии за прошлый период - это уже задача механизма перерасчетов, который "в рамках данной задачи использовать не надо"
Отправлено: sada от Октябрь 21, 2010, 06:58:58 pm
Отправлено: hapcher от Ноябрь 14, 2010, 05:04:03 pm
Обратите внимание!!! Добавила сторнирование премии, без использования перерасчетов.
Еще ни у кого такого не было
Вложения:
_3_06.dt
Отправлено: ruin от Ноябрь 14, 2010, 07:29:11 pm
Решение хорошее. Но
Quote (hapcher)
Добавила сторнирование премии, без использования перерасчетов.
Давай повторюсь - метод ПолучитьДополнение() получает сторно записи для планов видов расчетов которые используют период действия. У тебя дополнительные начисления не используют период действия, что правильно.
Спросишь как действовать тогда? Да никак. Тут выхода 2:
1. Неразумный - сделать премию зависящей от времени.
2. Разумный - Вообще ничего не делать по поводу сторнирования премии, а сказать экзаменатору что это дело механизма перерасчетов, а в задаче написано что его тут использовать не нужно. Но для этого нужно будет проставить галки ведущих видов расчетов.
Теперь замечания:
1. В регистре расчетов Основных начислений ты не используешь реквизит "Размер". Он бы тебе понадобился если б ты решила получить значение оклада для подразделения в момент первой записи движений документа. А у тебя размер оклада получается в момент расчета, соответственно это поле вообще не нужно, и сторнировать его тоже не нужно, это же реквизит, по нему не считаются итоги.
2. В запросе расчета командировки ты забыла связи проставить.
3. И список видов расчета в документе ЗП можно было б получить одной строкой: ОсновныеНачисления.ВыгрузитьКолонку("ВидыРасчета")
Отправлено: hapcher от Ноябрь 15, 2010, 02:55:27 pm
Отправлено: ruin от Ноябрь 15, 2010, 03:26:46 pm
Ну замечания так и остались, смотри их выше.
Попытку сторнирования вижу, но опять же эта штука разваливается при вводе, к примеру 2х командировок. В документ 000000002: 25.10-13.11, ну и введи вторую, к примеру 01.10-05.10. И у тебя отсторнируется двойная сумма. Если введешь 3 строки - 3 раза и т.д.
Просто ты пытаешься сделать те механизмы, которые уже существуют в 1с. На экзамене нужно показать как ты знаешь работу механизмов расчета зарплаты, а не то, как разрабатывать эти механизмы. Я бы на твоем месте не парился) Это сделать можно, но не нужно.
Отправлено: trantor от Ноябрь 15, 2010, 05:05:01 pm
а вот не является ли ошибкой что при разбиении командировки на периоды, используется ПериодРегистрации документа? Мне кажется правильнее брать ДобавитьМесяц(ТекущаяДатаНачала,-1) и ДобавитьМесяц(ТекущаяДатаОкончания,-1). Мы же для каждого периода(месяца) коммандироки должны посчитать базу предыдущего месяца.
Движение.БазовыйПериодНачало = НачалоМесяца(НачалоМесяца(ПериодРегистрации) - 1);
Движение.БазовыйПериодКонец = НачалоМесяца(ПериодРегистрации) - 1;
Отправлено: hapcher от Ноябрь 15, 2010, 07:10:49 pm
Quote (ruin)
Я бы на твоем месте не парился) Это сделать можно, но не нужно.
откуда такая уверенность, что на экзамене это не нужно? В задаче четко сказано, что премия не должна начисляться и механизм перерасчетов использовать не нужно.
Добавлено (15.11.2010, 19:10)
---------------------------------------------
trantor, да ты прав, исправила на:
Движение.БазовыйПериодНачало = НачалоМесяца(НачалоМесяца(ТекущаяДатаНачала) - 1);
Движение.БазовыйПериодКонец = НачалоМесяца(ТекущаяДатаНачала) - 1;
спасибо!
Отправлено: ut2k5 от Ноябрь 15, 2010, 08:50:27 pm
Quote
премия не сторнируется при вводе командировки задним числом.
зачем вводить людей в заблуждение? В условии четко сказано "Следует учесть, что данные о коммандировке не могут вводится в систему задним числом"....
Отправлено: ruin от Ноябрь 15, 2010, 08:59:50 pm
to hapcher
Вот немного подкрутил твою мысль. Если уж такое огромное желание сделать все)
Но все равно не советую на экзамене этим заниматься, т.к. времени не будет, и там они совсем другое проверяют...
Вложения:
3_06_r.dt
Отправлено: ut2k5 от Ноябрь 16, 2010, 10:36:53 am
Отправлено: ruin от Ноябрь 16, 2010, 10:39:34 am
Quote (ut2k5)
я так и не понял, какую мою мысль ты подкрутил
Мысль сторнировать премию.
Отправлено: hapcher от Ноябрь 16, 2010, 04:55:58 pm
Добавлено (16.11.2010, 16:55)
---------------------------------------------
Quote (ut2k5)
В условии четко сказано "Следует учесть, что данные о коммандировке не могут вводится в систему задним числом"....
В этой задаче могут, см. условие
Отправлено: hapcher от Ноябрь 16, 2010, 05:05:24 pm
Quote (ruin)
Вот немного подкрутил твою мысль. Если уж такое огромное желание сделать все)
Исправила, теперь работает. Спасибо за тест.
Добавлено (16.11.2010, 17:05)
---------------------------------------------
Теперь по замечаниям:
Quote (ruin)
1. В регистре расчетов Основных начислений ты не используешь реквизит "Размер". Он бы тебе понадобился если б ты решила получить значение оклада для подразделения в момент первой записи движений документа. А у тебя размер оклада получается в момент расчета, соответственно это поле вообще не нужно, и сторнировать его тоже не нужно, это же реквизит, по нему не считаются итоги.
"Размер" использую для наглядности. Не думаю, что это ошибка.
Quote (ruin)
2. В запросе расчета командировки ты забыла связи проставить.
Действительно забыла)) исправила в последнем варианте.
Quote (ruin)
3. И список видов расчета в документе ЗП можно было б получить одной строкой: ОсновныеНачисления.ВыгрузитьКолонку("ВидыРасчета")
Так ты не получишь ни оклад, ни премию, когда их нужно пересчитать при сторнировании
Вложения:
7572774.dt
Отправлено: ruin от Ноябрь 16, 2010, 05:14:41 pm
Quote (hapcher)
Quote (ruin)
3. И список видов расчета в документе ЗП можно было б получить одной строкой: ОсновныеНачисления.ВыгрузитьКолонку("ВидыРасчета")
3. И список видов расчета в документе ЗП можно было б получить одной строкой: ОсновныеНачисления.ВыгрузитьКолонку("ВидыРасчета")
Так ты не получишь ни оклад, ни премию, когда их нужно пересчитать при сторнировании
Это верно. Это в твоем исключительном решении не прокатит)
Но мое мнение все еще не поменялось, не стоит этим заниматься на экзамене: писать не нужные реквизиты, изобретать механизм сторнирования, который уже есть. Можно было просто сделать премию - основным начислением и вообще не заморачиваться на счет сторно - она б отсторнировалась как и оклад
Отправлено: hapcher от Ноябрь 16, 2010, 05:18:39 pm
Quote (ruin)
Можно было просто сделать премию - основным начислением и вообще не заморачиваться на счет сторно - она б отсторнировалась как и оклад
ну на фик, такой грех на душу брать))
Отправлено: ГотовлюсьКСпецу от Ноябрь 28, 2010, 03:10:54 pm
На экзамене сделал документ с разбивкой записей по периодам (для командировки) ,настроил Виды Расчетов, Создал регистры расчета, заполнил РС "график работы" на 2 месяца, не стал обработку править Решил быстрее руками дозабить данные по шестидневке (ушло 5 минут). И начал в консоле писать красивый запрос. И тут я столкнулся с непреодолимой сложностью. Обращаюсь я значит к виртуальной таблице ОСновныеНачисления.ГрафикРаботы по регистратору, а он записи мне выводит, А ЗначениеПериодДействи и ЗначениеФактическийпериоДействия - NULL!!! подумал забыл настроить связь с графиком проверил себя, все в порядке. Бился с этой проблемой потерял минут 40 решить не смог, чувствую до конца минут 20, плюнул на это и дописал запрос. и начал писать движения, и тут время кончилось. Не сдал. Пришел домой выполнил все то же самое дома. Дома все прекрасно работает как часы! Кроме Сторнирования. Не понимаю почему ПолучитьДопполнение() не получает не одной записи при вводе командировки в ноябре за октябрь! Может быть на экзамене несколько ДРУГАЯ Каркасная Конфигурация? И где мог быть косяк? не представляю!!! Посмотрите что не так. с ПолучитьДополнение() Задача 3.6
Вложения:
8247215.dt
Отправлено: ditoch от Декабрь 12, 2010, 11:53:13 am
Quote (ГотовлюсьКСпецу)
Посмотрите что не так. с ПолучитьДополнение() Задача 3.6
1. Нужно не Движение.ПериодРегистрации = НачалоМесяца(Дат); ,а Движение.ПериодРегистрации = НачалоМесяца(Дата);
2. После чего подправить:
Строка.ПериодРегистрации = ш.ПериодРегистрацииСторно;
Строка.ПериодДействияНачало = ш.ПериодДействияНачалоСторно;
Строка.ПериодДействияКонец = ш.ПериодДействияКонецСторно;
и все заработает!
Добавлено (12.12.2010, 11:53)
---------------------------------------------
Quote (ditoch)
ЗначениеФактическийпериоДействия - NULL!!!
или записи оклада вытеснялись командировкой (я такое заметил), или не введен был оклад для базового периода командировки
Отправлено: unknown181538 от Январь 10, 2011, 11:05:48 pm
Quote (trantor)
hapcher, а вот не является ли ошибкой что при разбиении командировки на периоды, используется ПериодРегистрации документа? Мне кажется правильнее брать ДобавитьМесяц(ТекущаяДатаНачала,-1) и ДобавитьМесяц(ТекущаяДатаОкончания,-1). Мы же для каждого периода(месяца) коммандироки должны посчитать базу предыдущего месяца.
Если мы будем брать для каждого месяца командировки базу предыдущего, то придется рассчитывать последовательно базу по месяцам, т.к. каждый месяц является базой для следующего. Я бы на экзамене просто взял месяц, предшествующий дате начала командировки.
Отправлено: AndreiPiter от Январь 21, 2011, 07:51:19 pm
Вложения:
AP_3.06.dt
Отправлено: Matcoder от Январь 23, 2011, 02:30:11 pm
Добавлено (23.01.2011, 14:30)
---------------------------------------------
Только вот командировка, если она протяженностью в несколько месяцев, сама себя в в свою базу не получает.
По-идее надо бы каждый месяц командировки расчитывать отдельно. Но это уже извращения
Вложения:
3_6_Matcoder.dt
Отправлено: rus от Январь 24, 2011, 08:00:47 am
Вложения:
3990173.dt
Отправлено: Gulf_Stream от Июнь 19, 2011, 06:36:58 pm
Вложения:
GS_3.06dt.dt
Отправлено: Slimper от Июнь 20, 2011, 05:31:09 pm
Отправлено: Gulf_Stream от Июнь 22, 2011, 05:56:03 pm
Отправлено: Gyd от Июнь 23, 2011, 08:57:04 am
Quote (Gulf_Stream)
только расчёты имеющие период действия,
согласен.
Отправлено: Urfin от Июль 18, 2011, 04:44:56 pm
Комрады, покритикуйте, пжл, если у кого будет время. Ох уж эти расчетные задачи..)
Спасибо.
Вложения:
1Cv8_Urfin_306.dt
Отправлено: RedLight от Декабрь 21, 2011, 11:22:19 am
Вложения:
RedLight_3_6.dt
Отправлено: sv_mikh от Январь 06, 2012, 11:27:28 am
На премию в принципе сразу забил. Но вот хотелось командировку текущего месяца правильно посчитать. Но как, если есть записи о сторно прошлого месяца + доначисления.
Выходит нужно сначала записать результаты сторно прошлого месяца по окладу и командировке и лишь потом считать базу для расчета командировки текущего месяца?
Получается, что если есть сторно прошлых месяцев то при расчете текущего месяца должны появиться приоритеты. Сначала прошлые считаем, записываем, потом текущие считаем, записываем?
В целом реализовал только сторно оклада прошлого месяца + доначисление командировки в прошлый месяц. Премия прошлого периода не пересчитывается, при командировке в прошлое база командировки текущего месяца считается не правильно... (без сторно оклада).
Вложения:
sv_mikh_03_06.dt
Отправлено: Альберт от Январь 07, 2012, 11:09:02 pm
Вложения:
3_06.dt
Отправлено: max_osodoev от Январь 30, 2012, 04:39:52 pm
Вложения:
3.6_max_os.dt
Отправлено: Tommy от Февраль 27, 2012, 02:07:09 pm
Вложения:
toma_3_6.dt
Отправлено: Lazutin от Февраль 27, 2012, 02:31:49 pm
1. Нет сторно в документ НачислениеЗарплаты. Т.к. сказано, что "Следует учесть, что данные о командировке могут вводиться в систему задним числом.", значит надо еще при проведении документа вводить данные о сторно (поможет метод ПолучитьДополнение()).
2. Для плана видов расчета ДопНачисления лучше установить зависимость от базы "по периоду регистрации", т.к. премия начисляется в том же расчетном периоде.
3. Командировка вообще не считается, попробуйте введите еще 1 документ за март с видом расчета Командировка.
4. Процедуру расчета начислений следует выносить в общий модуль(быстродействие и удобство перерасчетов, ну и просто рекомендуется)
5. Не правильно соединяются данные графика для расчета Оклада с РС ШкалыОкладов, не учли если не будет верхней границы, т.е. отработано часов >100 и нет верхней границы например. (в соединение нужно добавить что-то типа ОсновнойДанныеГрафика.ЗначениеФактическийПериодДействия < ШкалаОкладов.Макс ИЛИ ШкалаОкладов.Макс = 0)
6. В условии Если МассивОсновных.Найти(ПланыВидовРасчета.ОсновныеНачисления.Командировка) Тогда забыли <> Неопределено, следовательно не считается командировка
7. В диаграмме Ганта перед построением не очищаете ее. нужно использовать Диаграмма.Очистить()
Отправлено: Tommy от Февраль 27, 2012, 02:59:04 pm
со всем согласна, большое спасибо
Отправлено: nodalt от Апрель 11, 2012, 01:35:25 am
Вложения:
nodalt_3_6.dt
Отправлено: kow1976 от Май 08, 2012, 07:42:47 am
Не сторнируется полностью оклад если вводим командировки задним числом за весь предыдущий месяц.
Вложения:
s7576123.jpg
Отправлено: kow1976 от Май 08, 2012, 07:54:30 am
Quote (Lazutin)
2. Для плана видов расчета ДопНачисления лучше установить зависимость от базы "по периоду регистрации", т.к. премия начисляется в том же расчетном периоде.
Здесь только период действия. Так как сторно записи попадут в базу начисления премии если база будет по периоду регистрации. (-100( оклад за прошлый месяц)+1000(оклад за настоящий месяц))*%премии.
Такой вариант решения задачи.
Спасибо за комментарии и замечания.
Вложения:
kow1976_3.6.dt
Отправлено: Teriban от Июнь 05, 2012, 11:37:10 am
Вложения:
306_v1.dt
Отправлено: alex7six от Январь 13, 2013, 10:38:03 pm
Отправлено: abeille от Май 30, 2013, 05:01:21 am
Отправлено: fimanich от Июль 17, 2013, 02:18:19 pm
Вложения:
fimanich_03_06.dt
Отправлено: TuMyP1985 от Август 21, 2013, 05:20:41 pm
Вложения:
KTT_3_6.dt
Отправлено: artfa от Сентябрь 07, 2013, 07:13:22 pm
Вложения:
1085307.dt
Отправлено: artfa от Октябрь 09, 2013, 10:51:30 pm
Вложения:
0033168.dt
Отправлено: svsource от Ноябрь 06, 2013, 04:36:48 pm
Пример
1.07 - 31.07 - Иванов по окладу - 10000.
==========================
далее
1.08 - 31.08 - Иванов по окладу - 10000
тут же вводим в августе
командировку
с 27.07 по 30.11 Иванов
==========================
итого
имеем за июль - вытеснение оклада с 27.07 по 31.07
полностью вытеснение оклада за август и ввод записей за сентябрь, октябрь, ноябрь.
- записи создаем документом "начисление зарплаты" за август.
производим расчет за август. - имеем - оклад с 27.07 по 31.07 сторно. - запись получаем через дополнение().
далее командировка с 27.07 по 31.07 - 0..... т.к. база для расчета по условию задачи для командировки - 01.06 - 30.06
1. Правильно ли это?
далее ну понятно командировка за август (вытеснила оклад за август) - базу берем за июль... по условию задачи
база командировки - ВСЕ начисления за пред. месяц. т.е. 01.07 - 31.07
2. А вот дальше ... Командировка сентябрь, октябрь и ноябрь... - у меня получается база о... и результат 0=00. :)
В принципе ясно из-за чего - просто рассчитанной базы для очередного месяца нет в базе. Если рассчитывать помесячно
и писать в базу записи регистра расчета - то получается как бы запрос в цикле . Это не годится. А если считать базу для командировки остальных месяцев по июлю - это нарушение условий задачи. Что Вы думаете по этому вопросу? Что то эта задача не идет у меня.
Я понимаю что это экзаменационная задача а не реальная. Но все же как то криво выходит с командировкой.
C Уважением, Сергей.
Отправлено: artfa от Ноябрь 06, 2013, 05:37:13 pm
1. да правильно, т.к. по условию задачи база берется за предыдущий месяц, а не за предшествующие 30 дней.
2. да именно запрос в цикле, от этого никуда не денешься в этой задаче, для цикла я и ввел реквизит Приоритет по количеству которого идет цикл, и который (приоритет) увеличивается на 1 с каждым месяцем начисления командировки
Отправлено: mavayka от Ноябрь 13, 2013, 04:18:47 pm
Вложения:
mav_3_6.dt
Отправлено: artfa от Ноябрь 13, 2013, 05:14:21 pm
Цитата mavayka (
)
)Помогите, пожалуйста, найти ошибку
Отправлено: mavayka от Ноябрь 13, 2013, 05:49:16 pm
Отправлено: Alexander от Ноябрь 16, 2013, 09:50:04 am
1. Оклад сторнируется с учетом того, что начальное значение оклада может поменяться. (Хотя я внутренне не согласен что часы в командировке уменьшают Начальное значение оклада). Так как при расчете начального оклада мы не берем в расчёт часы командировки.
2. Премия сторнируется (если конечно ее введешь для расчета)
3. Командировка считается с учетом самой себя. (Ввел цикл по периоду действия с записью движений)
-----
Кроме того в выложенной базе задачи 1.6 и 2.5 - потому что делаю сериями - не обращайте внимания)
Если кто посмотрит с целью покритиковать - буду признателен.
Вложения:
Kul_3_6.dt
Отправлено: mikas-2008 от Декабрь 15, 2013, 11:01:27 pm
Да и самайлы конечно на любителя. 
Интересная задача.
Alexander,
Вот на счет сторнирования премии я б поспорил, так как по идее, если командировка введется задним числом, тогда оклад сторнируется и изменится его период действия через вытеснение. Когда это произойдет необходимо будет отследить эти изменения через перерасчеты и перепровести документ, в котором был рассчитан оклад и премия на него. При перерасчете все суммы встанут на свои места, но в этой задаче перерасчеты делать не требуется. Но это мое мнение.
По поводу расчетов командировки, я пошел по пути приоритетов. Все основные начисления и дополнения у меня с нулевым приоритетом, а командировки начинаются с единицы и до бесконечности (в зависимости от количества интервалов в месяц). Т.о. все командировки будут рассчитываться последовательно и сами для себя будут базой предыдущего периода.
Выкладываю свое решение.
Вложения:
mikas_3.06.dt
Отправлено: IT_PROGRAMMIST от Февраль 08, 2014, 02:45:05 pm
Вложения:
3_6_IT_PRG.dt
Отправлено: non1ka от Февраль 08, 2014, 09:26:15 pm
Цитата
Движения.ОсновныеНачисления.Записать(, Ложь);
Значение параметра должно быть Истина
<ТолькоЗапись>
(необязательный)
Тип: Булево.
Определяет режим записи набора. Истина - производится
только запись набора; Ложь - производится
пересчет фактического периода действия и ввод записей перерасчетов.
Добавлено (08.02.2014, 21:11)
---------------------------------------------
mikas-2008,
Цитата
Вот на счет сторнирования премии я б поспорил, так как по идее, если командировка введется задним числом, тогда оклад сторнируется и изменится его период действия через вытеснение. Когда это произойдет необходимо будет отследить эти изменения через перерасчеты и перепровести документ, в котором был рассчитан оклад и премия на него. При перерасчете все суммы встанут на свои места, но в этой задаче перерасчеты делать не требуется. Но это мое мнение.
Согласен с вами на 100 %. Сторнирование премии это вопрос перерасчета, а в данной задачи перерасчеты реализовывать не нужно.
Добавлено (08.02.2014, 21:17)
---------------------------------------------
kow1976,
1. Добавлено подразделение в качестве измерения регистров расчета. В задаче нет необходимости учитывать базу по подразделениям
2. Нет реквизита "График" в документе "Начисление заработной платы"
3. При сторнировании использование ресурса "ФактЧасы", мне кажется вы усложнили решение.
4. Расчет заработной платы не вынесен в отдельный модуль.
Добавлено (08.02.2014, 21:26)
---------------------------------------------
mikas-2008, Замечания
1. Дополнительные начисления на должны "Использовать период действия" не влияют на вытеснение.
2. У "Премии" вы установили зависимость по периоду регистрации. Мне кажется под термином "в том же расчетном периоде оклада" имеется ввиду начислений оклада = периоду начисления премии. Хотя Ваш вариант может так же быть правильным. Я спрошу у Павла как правильно понимать данное условие задачи.
Отправлено: non1ka от Февраль 08, 2014, 09:31:28 pm
Необходимо рассчитанное значение оклада помещать в реквизит "Размер" регистра расчета.
Это требование к устойчивости системы. Это относится к курсам валюты, коэффициентам единиц измерения и т.п.
Выкладываю свой вариант решения
Вложения:
9052658.dt
Отправлено: IT_PROGRAMMIST от Февраль 08, 2014, 10:04:13 pm
Реквизит " Размер" для регистра расчета Основные начисления в рамках данной задачи считаю не нужным( мы не можем его использовать как вспомогательный при расчете) , так как оклад определяется от фактически отработанного времени.
По поводу
Цитата
Это требование к устойчивости системы
по вашему решению:
1) зачем вы при расчете основных начислений рассчитываете с начало оклад, а потом командировку? Не проще сделать это в одном запросе?
Поигрался с данными - ошибок не нашел...
Отправлено: non1ka от Февраль 09, 2014, 02:58:59 pm
Цитата
Реквизит " Размер" для регистра расчета Основные начисления в рамках данной
задачи считаю не нужным( мы не можем его использовать как
вспомогательный при расчете) , так как оклад определяется от фактически
отработанного времени.
задачи считаю не нужным( мы не можем его использовать как
вспомогательный при расчете) , так как оклад определяется от фактически
отработанного времени.
В механизмах расчета это больше несет рекомендательный характер.
Но что касается курсов валют и коэффициентов единиц измерения это базис любой информационной системы,
Любое перепроведение документа, не должно изменять состояние информационной системы до момента перепроведения.
Во всех задачах с валютами, необходимо помещать значение курса валюты в реквизиты документа.
Мне кажется за это балы на экзамене не снизят, но так было бы правильнее.
Цитата
1) зачем вы при расчете основных начислений рассчитываете с начало оклад, а
потом командировку? Не проще сделать это в одном запросе?
потом командировку? Не проще сделать это в одном запросе?
Командировка зависит от оклада, если оклад не будет посчитан у командировке не будет базы. а с условием того, что командировка может вводится с
01.01 по 31.03, если не будет посчитан оклад за январь не будет базы.
Добавлено (09.02.2014, 14:58)
---------------------------------------------
Цитата
оклад определяется от фактически отработанного времени.
Отправлено: ARMchair от Март 19, 2014, 09:51:44 pm
1. В вашем решении при сторнировании оклада он рассчитывается "заново" (исходя из оклада, соответствующего сторнируемым часам).
На мой взгляд, правильнее было бы брать за основу начальный оклад, полученный ранее (который хранится в поле "Размер")
2. При рассчете очередного месяца командировки, вводимой за несколько месяцев, при получении базы не учитывается результат самой этой командировки.
3. Нет проверки на NULL ресурсов таблицы ДанныеГрафика (правда, не уверен, что это критично)
Отправлено: ARMchair от Март 19, 2014, 09:52:42 pm
Вложения:
ARMchair_3_06.dt
Отправлено: Leo705 от Апрель 02, 2014, 11:49:12 am
Вложения:
Leo705_3.6.dt
Отправлено: MKIV от Июнь 16, 2014, 03:00:25 pm
1) сторнирование премии. если был бы период действия у премии, то можно было бы просто поставить период действия базовый и вытеснять премию командировкой, но по условию задачи премия рассчитывается процентом от базы в расчетном периоде, т.о. премия не должна иметь период действия, поэтому этот вариант в данном случае не применим (этот вариант даже отмечен в списке ошибок).
Просмотрел несколько вариантов решений и ниодин мне до конца не понравился в этом плане. Поясню:
_большинство склоняется к тому, чтобы отдать решение этого вопроса механизму перерасчетов. Однако у меня этот вариант вызывает вопросы: поставил у премии оклад ведущим. сделал начисление оклада и премии, сделал начисление командировки со сторнированием оклада, пытаюсь консолью запросов получить базу дополнительные начисления по основным начислениям (чтобы потом в случае необходимости сделать перерасчет) и после сторнирования база остается без учета сторно-движений. глюк?
_было одно решение, которое меня больше других заинтересовало: в случае формирования таблицы сторно для вида расчета оклад происходит формирование дополнительных движений сторно по виду расчета премия, хотя автор сделал там ряд упрощений и не доделал до конца. я представляю как доделать этот вариант. Однако на решение приется потратить дополнителььное время.
2)разбитие периода действия командировки на несколько периодов. условие, что базой является предыдущий месяц можно тратоквать по-разному. предыдующий месяц по отношению к периоду регистрации один в любом случае, предыдущий месяц по отношению к периоду действия может меняться.
Вложения:
MKIV_306.dt
Отправлено: eswahr от Июль 15, 2014, 10:22:49 pm
Задачу решал на платформе 8.3.5.1068.
Прикрепления: 3.06.dt(161Kb)
Вложения:
4526924.dt
Отправлено: Alyx Ruby от Август 18, 2014, 02:28:44 pm
Цитата eswahr ()
)Большая просьба взгляните на решение задачи 3.06. Уже неделю бьюсь, а механизм расчета зависимости от базы (при расчете премии) почему то не работает. Никак не могу получить базу для расчета премии. Наверняка пустяковая ошибка, а найти ее не получается! Задачу решал на платформе 8.3.5.1068.
Отправлено: Evgeny от Март 12, 2015, 03:33:39 pm
Отправлено: rusmosav от Апрель 25, 2015, 04:25:10 pm
Отправлено: rufat2005 от Апрель 26, 2015, 06:59:44 pm
Билет № 2 , текст "В течение расчетного периода первоначальное значение оклада может быть неоднократно изменено. В информационной базе необходимо хранить историю его изменения. Расчет должен проводиться исходя из действующего на рассчитываемую дату начального значения оклада. Например, если начальное значение оклада изменилось 10 августа, то до 10 августа при расчете берется старое значение, а начиная с 10 августа – новое. "
то тут мы разбиваем период действия по мере изменения оклада, т.е. в данном случае если Период действия Начало 01.08 конец 31.08 одной строкой занесено то мы разбиваем его на 2 записи , 01.08-09.08 и 10.08-31.08, Хоть и период регистрации стоит например 01.09.
Но почти во всех решениях если в задача написано " Первоначальное значение оклада может изменяться не чаще, чем один раз в день, но берется на начало расчетного периода. "
То берут данные по периоду регистрации, т.е.
Оклад 01.08 - 10 000
Оклад 01.09 - 15 000
Период действия 01.08-.31.08
Период Регистрации 01.09
То берут 15 000 по периоду регистрации.
Мне как бухгалтеру это кажется ошибочным. Пожалуйста обясните этот момент.
Когда нужно по периоду регистрации и когда по периоду действия если учитывать что они могут отличаться
Отправлено: rufat2005 от Апрель 27, 2015, 06:50:12 am
Видимо нужно читать буквально, т.е. Расчетный период - период когда делаем расчет, т.е. период регистрации, и рассчитываемый период , период за которую делается расчет, т.е. периоды действия
Отправлено: Natain14 от Май 28, 2015, 03:24:39 pm
Отправлено: axel_work от Ноябрь 19, 2015, 07:01:50 pm
То есть она должна вытесняться командировкой?
Если поместить премию в Доп. начисления, то в текущем периоде нормально получается - оклад вытесняется командировкой, премия считается после основных начислений - и соот-но уменьшается ее размер. Хотя в условиях задачи больше похоже на период действия.
Но если командировку задним числом ввести, то сторнируется только оклад, премия не изменяется. Получается невыполнение условий.
Отправлено: Kickout от Декабрь 03, 2015, 03:30:59 pm
По поводу сторно записи командировки и премии. Если происходит сторно запись, то это отразится в следующем начислении, т.е. если в августе при выплате ЗП вводится сторно запись за июль, то ЗП за август уменьшается ровно на сторно запись, а т.к. у нас премия целиком зависит от ЗП то она уже будет считаться от измененной ЗП. Короче говоря в условии этот момент, просто игра слов чтобы запутать. + для чего делаются сторно записи? Правильно они вводятся когда уже все налоги заплачены и все начислено, но то что сотрудник где то был(командировка, болел, быхал и т.д.) надо учесть и поэтому этот учет произойдет в текущем начислении.
Отправлено: axel_work от Декабрь 04, 2015, 03:14:50 pm
Врядли кто то прочтет но вдруг.
По поводу сторно записи командировки и премии. Если происходит сторно запись, то это отразится в следующем начислении, т.е. если в августе при выплате ЗП вводится сторно запись за июль, то ЗП за август уменьшается ровно на сторно запись, а т.к. у нас премия целиком зависит от ЗП то она уже будет считаться от измененной ЗП. Короче говоря в условии этот момент, просто игра слов чтобы запутать. + для чего делаются сторно записи? Правильно они вводятся когда уже все налоги заплачены и все начислено, но то что сотрудник где то был(командировка, болел, быхал и т.д.) надо учесть и поэтому этот учет произойдет в текущем начислении.
За ответ спасибо. Мысль уловил. То есть ранее начисленная премия не изменится, но в текущем расчетном периоде размер премии уменьшится. Единственное "но" - в условии задачи явно сказано что начисление по окладу и премии не должно производится, когда сотрудник в командировке (получается должно вытесняться?).
Отправлено: aevdovin от Апрель 10, 2016, 03:02:50 pm
У меня основная сложность в задаче была с тем - как написать запрос, вытаскивающий данные базы 2-х ПВР, данные по кол-ву рабочих часов за прошлый месяц и данные по факт.часам для каждой записи ВР Командировка. Но в итоге разобрался, считаю что все получилось)
Отправлено: Kickout от Июнь 28, 2016, 04:45:50 pm
Врядли кто то прочтет но вдруг.
По поводу сторно записи командировки и премии. Если происходит сторно запись, то это отразится в следующем начислении, т.е. если в августе при выплате ЗП вводится сторно запись за июль, то ЗП за август уменьшается ровно на сторно запись, а т.к. у нас премия целиком зависит от ЗП то она уже будет считаться от измененной ЗП. Короче говоря в условии этот момент, просто игра слов чтобы запутать. + для чего делаются сторно записи? Правильно они вводятся когда уже все налоги заплачены и все начислено, но то что сотрудник где то был(командировка, болел, быхал и т.д.) надо учесть и поэтому этот учет произойдет в текущем начислении.
За ответ спасибо. Мысль уловил. То есть ранее начисленная премия не изменится, но в текущем расчетном периоде размер премии уменьшится. Единственное "но" - в условии задачи явно сказано что начисление по окладу и премии не должно производится, когда сотрудник в командировке (получается должно вытесняться?).
Прошло пол года, но отвечу и скорее всего не актуально. У тебя премия не имеет продолжительности во времени как в задаче 3,4 где они в шахте трудятся, премия это единоразовое начисление и тогда встает вопрос, как командировка может вытеснить премию? правильно только одним способом, уменьшив оклад(ну или если была командировка значит сотруднику премия не положена, но т.к.ю это условие посложнее реализовать остановимся на первом варианте), который он собственно и вытесняет а раз премия зависит от оклада то и премия изменится.
И небольшой момент. Буду благодарен если кто то вдруг понимает логику автора задачника.В условии сказано что база для командировки берется за предыдущий месяц и командировка может вносится не ха месяц а за какой нибудь период, даже за год, отсюда следует как брать этот месяц? от даты регистрации или от периода начала действия записи?
потому что во втором случае будет происходить приоритет расчета записей, т.к. командировка сама для себя является базой и чтобы получить базу за май, нужная запись за апрель(это я для того случая когда в феврале вводится запись что он будет в командировке до июля например) и следовательно логика расчета уже друая, добро пожаловать в запрос в цикле, но знаю что в данном разделе он допустим
Отправлено: axel_work от Июль 13, 2016, 10:50:20 am
Врядли кто то прочтет но вдруг.
По поводу сторно записи командировки и премии. Если происходит сторно запись, то это отразится в следующем начислении, т.е. если в августе при выплате ЗП вводится сторно запись за июль, то ЗП за август уменьшается ровно на сторно запись, а т.к. у нас премия целиком зависит от ЗП то она уже будет считаться от измененной ЗП. Короче говоря в условии этот момент, просто игра слов чтобы запутать. + для чего делаются сторно записи? Правильно они вводятся когда уже все налоги заплачены и все начислено, но то что сотрудник где то был(командировка, болел, быхал и т.д.) надо учесть и поэтому этот учет произойдет в текущем начислении.
За ответ спасибо. Мысль уловил. То есть ранее начисленная премия не изменится, но в текущем расчетном периоде размер премии уменьшится. Единственное "но" - в условии задачи явно сказано что начисление по окладу и премии не должно производится, когда сотрудник в командировке (получается должно вытесняться?).
Прошло пол года, но отвечу и скорее всего не актуально. У тебя премия не имеет продолжительности во времени как в задаче 3,4 где они в шахте трудятся, премия это единоразовое начисление и тогда встает вопрос, как командировка может вытеснить премию? правильно только одним способом, уменьшив оклад(ну или если была командировка значит сотруднику премия не положена, но т.к.ю это условие посложнее реализовать остановимся на первом варианте), который он собственно и вытесняет а раз премия зависит от оклада то и премия изменится.
И небольшой момент. Буду благодарен если кто то вдруг понимает логику автора задачника.В условии сказано что база для командировки берется за предыдущий месяц и командировка может вносится не ха месяц а за какой нибудь период, даже за год, отсюда следует как брать этот месяц? от даты регистрации или от периода начала действия записи?
потому что во втором случае будет происходить приоритет расчета записей, т.к. командировка сама для себя является базой и чтобы получить базу за май, нужная запись за апрель(это я для того случая когда в феврале вводится запись что он будет в командировке до июля например) и следовательно логика расчета уже друая, добро пожаловать в запрос в цикле, но знаю что в данном разделе он допустим
Добрый день! Еще актуально :)
Ну по поводу премии понятно, у нее зависимость от оклада, а оклад вытесняется командировкой. просто формулировка в задача нечеткая. Ее можно толковать вплоть до того, что вообще при наличии командировки пользователь начисления оклада и премии должен убирать в данном месяце.
Что касается логики, то обычно отсчет от периода регистрации. Ведь логично получить какой-то средний доход (в данном случае за предыдущий месяц), который и будет выплачиваться во время командировки (хоть год). По аналогии с отпуском (там обычно тоже жестко график задается = пятидневка), когда в задачах получается например за 3 предыдущих месяца.
А если вариант пробовать от начала периода записи, то тогда нужна зависимость по периоду действия - и получится следующее: оклад и премия например в этом месяце - за полмесяца, со второй половины пошла командировка длиной в полгода. первая запись - полмесяца - берет от предыдущего месяца начисления, вторая - за этот месяц (пол-оклада и пол-командировки с половиной премии), а дальше - командировка сама от себя базу начинает получать - что достаточно бессмысленно.
Кстати с зависимостью по периоду действия, сторно с командировкой криво считается. В решении у меня зависимость по периоду регистрации, так как, если использовать для Осн. нач. зависимость по периоду действия и перепровести документ за июль, то командировка станет 300 руб. за месяц (оклад полностью отсторнируется и в базу войдет только премия - что есть неправильно).
Так что вариант второй, с базой от начала записи выглядит неверным. В билетах есть задачи, где надо запрос в цикле, и начисление зависит само от себя, но там сформулировано четко и понятно, по другому просто не сделаешь.
Отправлено: axel_work от Июль 13, 2016, 10:57:54 am
Отправлено: Kickout от Июль 13, 2016, 12:21:08 pm
Кстати с зависимостью по периоду действия, сторно с командировкой криво считается.
[/quote]
У тебя база считается криво при сторно записи?
Двойной размер идет? (потоу что у меня он вначале берет нормальную базу а потом почему то берет ее в двойном размере)
поговорил с прогером, который на работе, он предположил что все таки база берется от периода действия.
а по поводу двойной базы он сам не понял почему база идет в двойном размере, возможно ошибки платформы?
и еще один момент, который меня волновал, при зависимости по периоду регистрации базовый период надо указывать за месяц или за 1 день?
Отправлено: axel_work от Июль 13, 2016, 03:44:30 pm
Мой файл приложенный в том сообщении скачай и посмотри, так наглядней будет. Криво - не в смысле ошибочно, двойных записей там нет, а в смысле - когда базу получаешь за прошлый месяц, но в текущем например у тебя сторно запись вводится командировка за весь прошлый месяц. При зависимости по периоду действия - сторно оклада сложится с окладом прошлого месяца (период действия) и будет = 0, останется в базе только премия прошлого месяца - если в этом месяце тоже есть командировка, то будет фигово. Ведь сторно запись имеет период регистрации текущим месяцем, а действия - прошлым.
Просто в моем примере поменяй вариант зависимости и перепроведи последний документ - сразу увидишь.
При зависимости по периоду регистрации базовый период указываешь полностью (в данном случае месяц). Это и более удобно, так как не надо думать какая зависимость по базе.
Отправлено: alfalume от Август 20, 2016, 12:20:52 pm
Отправлено: mxs89 от Ноябрь 15, 2017, 09:57:05 am
мое решениеполучаете плановое время за период регистрации, должны за пред. месяц.
Отправлено: ТимТим88 от Апрель 11, 2018, 12:25:08 pm
Вопрос: при вводе командировки с 25.01 по 05.03 - как считать Базу за Февраль?
Ставить командировку Базовым ВР для самой себя? Начислений по окладу в феврале не будет
Отправлено: ТимТим88 от Ноябрь 30, 2018, 05:06:00 pm
т.е. если 25.01 - 05.03, то база - это начисления за декабрь.
Отправлено: eiffil от Декабрь 03, 2018, 03:45:18 pm
Добрый день! База для командировки: берется предыдущий месяц месяц с даты начала командировки.
т.е. если 25.01 - 05.03, то база - это начисления за декабрь.
Если у вас в регистре должно быть 3 записи (т.к. период действия не может переходить из месяца в месяц). А дальше уже как хотите, на мой взгляд, для каждой записи базовый период должен быть разный. Т.е. для записи 25.01-31.01 - база в декабре, для записи 01.02-28.02- январь, 01.03-05.03 - февраль.
ПС: сейчас на экзамене нет задач с переходящими периодами действия.
Отправлено: Stanislaw от Май 11, 2020, 11:47:00 am
Отправлено: А_Б_В от Август 09, 2020, 10:30:39 pm
Отправлено: А_Б_В от Август 11, 2020, 09:10:29 am
Отправлено: Ильнур1975 от Август 11, 2020, 02:16:24 pm
... но не уверен можно ли так корректировать премию, когда командировка вводится задним числом.
Если работает то хорошо.
В том случае когда задним числом вводится командировка, платформа через механизм вытеснения сделает перерасчет оклада. Это одно из условий задачи.
А вот чтобы премия после этого пересчиталась - это нужно написать программный перерасчет, используя объект Перерасчеты. А по условию задачи механизм перерасчетов не надо использовать.
Так что задача "требует" не завершенного решения в части перерасчета премии.