Отправлено: old_guest от Сентябрь 09, 2010, 06:20:58 pm
Вложения:
3_1.dt
Отправлено: ut2k5 от Сентябрь 16, 2010, 03:54:20 pm
но задача у тебя как то не так решена..., что то я не увидел там не правильно рассчитаной коммандировки, даже оклад за январь у тебя не понятно почему так раскидало в не сколько записей, но я в СПР слаб, поэтому умничать не буду...
Отправлено: old_guest от Сентябрь 17, 2010, 12:44:39 pm
А что значит оклад за январь раскидало в несколько записей, не совсем понятно?
В расчете командировок не учитывается выходные, ведь по условию задания нужно получать данные по пятидневке или это неправильно?
Отправлено: savotii от Сентябрь 17, 2010, 12:47:15 pm
прошу прокомментить.
Еще интересует такой вопрос, увы полный функционал запросов я пока не знаю, можно ли получить запросом, на тему командировки,
данные за 2 пред месяца, если можно синтаксис такого кусочка, чтоб иметь представление.
Спасибо
Вложения:
_3-1__.cf
Отправлено: ut2k5 от Сентябрь 17, 2010, 04:39:23 pm
savotii, cf не варик выкладывать, надо бы dt
savotii, при попытки провести в одном документе и оклад и командировку при выполнении запроса:
Code
Ошибка SQL: Деление на 0
по причине:
Деление на 0 значения типа Numeric
по причине:
Деление на 0 значения типа Numeric
и это при любой попытки сформировать командировку в сентябре, причем за июль и август - оклад и премия вроде отлично и правильно рассчитались, хотел разобраться где беда, но скажу тебе, что если ты хочешь, что бы кто-то посмотрел твое решение, оформляй код читабельно, береги труд других..., вообщем сложно разобраться в твоем коде...
с отчетом вообще беда, он по сотруднику за все три периода выводит в разных строчках, а мне кажется, что должно быть сгрупированно, как по виду расчета так и по сотруднику..., и убери ПериодРегистрации из детальных записей отчета
Отправлено: ut2k5 от Сентябрь 17, 2010, 04:50:02 pm
Кста, Yanakaev, только что посмотрел, твое решение на мой взгляд абсолютно правильное, только не могу понять, как ты одним запросом для основных начислений выбрал и оклад и командировку, буду разбираться...
Вложения:
Quest_3_1.dt
Отправлено: old_guest от Сентябрь 17, 2010, 05:01:07 pm
Во вложении снимок всего регистра расчета "Основные начисления" и отчета
Вложения:
s5534999.png
s8638117.png
Отправлено: ut2k5 от Сентябрь 17, 2010, 05:11:35 pm
Отправлено: old_guest от Сентябрь 17, 2010, 05:25:59 pm
Добавлено (17.09.2010, 17:25)
---------------------------------------------
ut2k5, Не увидел сообщение
Quote
одним запросом для основных начислений выбрал и оклад и командировку
очень просто предварительно записав основные начисления и в этот момент регистр расчета мне все рассчитал и базу и параметры.
Отправлено: ut2k5 от Сентябрь 17, 2010, 05:33:03 pm
я тебе там репутацию добавил...
Отправлено: old_guest от Сентябрь 17, 2010, 05:44:20 pm
Отправлено: savotii от Сентябрь 18, 2010, 09:20:15 am
Quote (ut2k5)
savotii, cf не варик выкладывать, надо бы dt
savotii, при попытки провести в одном документе и оклад и командировку при выполнении запроса:
Code
Ошибка SQL: Деление на 0
по причине:
Деление на 0 значения типа Numeric
savotii, при попытки провести в одном документе и оклад и командировку при выполнении запроса:
Code
Ошибка SQL: Деление на 0
по причине:
Деление на 0 значения типа Numeric
и это при любой попытки сформировать командировку в сентябре, причем за июль и август - оклад и премия вроде отлично и правильно рассчитались, хотел разобраться где беда, но скажу тебе, что если ты хочешь, что бы кто-то посмотрел твое решение, оформляй код читабельно, береги труд других..., вообщем сложно разобраться в твоем коде...
с отчетом вообще беда, он по сотруднику за все три периода выводит в разных строчках, а мне кажется, что должно быть сгрупированно, как по виду расчета так и по сотруднику..., и убери ПериодРегистрации из детальных записей отчета
на счет СФника , профтыкал, на счет кода постараюсь более читабельным , на счет отчета , яж грю не совсем понял, про группировки то понятно, про период регистрации нет, в отчете он же должен быть?
Отправлено: ut2k5 от Сентябрь 22, 2010, 01:02:29 pm
Отправлено: Zhora_Vlg от Октябрь 02, 2010, 12:32:39 pm
Выходит нужно делать каждый вид расчета отдельным запросом.
Отправлено: old_guest от Октябрь 02, 2010, 06:32:23 pm
Отправлено: baksha_bni от Октябрь 07, 2010, 10:06:27 am
Вложения:
3_01_Baksha_bni.dt
Отправлено: sada от Октябрь 07, 2010, 10:45:26 am
вот это жесть: планывидоврасчета.Начисления.НайтиПоНаименованию("командировка"), - создай предопределенный вид расчета
Оклад в документе подставляешь, потом можно исправить на любой, а надо ограничить его изменение не чаще чем 1 раз в день? (лучше сразу из регистра сведений брать)
Проверки заполнения в документе совершенно лишние
Для чего вложенный запрос в отчете ? Таблицу не сгруппировал, параметр дата2 на конец дня не установил.
Отправлено: baksha_bni от Октябрь 07, 2010, 12:56:18 pm
2)насчет оклада: не совсем понял твой вопрос, но по условию задачи: "первоначальное значение оклада может изменятся не чаще, чем один раз в день, но берется на начало расчетного периода"....это условие у меня полностью выполняется,т. к. в регистре сведений стоит периодичность день, а в документе если выбрать оклад то автоматически подставляется его размер на начало расчетного периода.....
3) насчет проверок: они точно не лишнии, т. к. если мы их уберем то создадим ситуацию когда не все нужные поля будут записаны, следовательно результат будет расчитан не правильно.....
4) вложенный запрос нужен для того чтобы условия накладывались сразу на две объединенные таблицы.....
параметр дата2 не нужно ставить на конец дня, т. к. мое условие накладывается на период регистрации, следовательно дата2 будет начало дня или конец на результат это никак не повлияет......
надеюсь доступно объяснил))))С уважением baksha_bni
Отправлено: sada от Октябрь 07, 2010, 01:46:23 pm
Quote (baksha_bni)
вряд ли будет ошибкой и т. к. это такая мелочь я не стал заморачиваться...
дело твое конечно, но это не мелочь.
Quote (baksha_bni)
в регистре сведений стоит периодичность день, а в документе если выбрать оклад то автоматически подставляется его размер на начало расчетного периода.....
В твоем решении не важно какой оклад стоит в регистре и что там периодичность день , что введут в документе то и будет начислено, хоть каждые 5 минут меняй. (у тебя регистр используется для облегчения ввода , а не для ограничения изменения).
Quote (baksha_bni)
насчет проверок: они точно не лишнии, т. к. если мы их уберем то создадим ситуацию когда не все нужные поля будут записаны, следовательно результат будет расчитан не правильно.....
Если на то пошло , то можно еще кучу проверок навтыкать (на дубли строк, на выбор не помеченных на удаление элементов, на соответсвие подразделений и сотрудников...) это конечно все хорошо , но на экзамене некогда будет этим заниматься, экзамен по основным механизмам платформы а не по юзабилити. Я этого делать не буду.
Quote (baksha_bni)
параметр дата2 не нужно ставить на конец дня, т. к. мое условие накладывается на период регистрации, следовательно дата2 будет начало дня или конец на результат это никак не повлияет......
согласен
Отправлено: baksha_bni от Октябрь 08, 2010, 04:50:47 am
Отправлено: sada от Октябрь 08, 2010, 05:00:22 am
Отправлено: ut2k5 от Октябрь 08, 2010, 11:45:22 am
Code
надо ограничить доступность у поля размер
и вообще от "бантиков" открестись, у тебя в модуле формы должно быть не больше 3-4 строк кода, основная работа по задаче должна производится в модуле документа и общих модулях расчета... не к тому экзамену видимо готовишься...
посмотри видео Чистова на тему СПР..., очень помогает в освоении расчетных механизмов, я до них вообще никак не мог понять чем отличается фактический период действия от базового [шучу]
Отправлено: d1mka22091988 от Ноябрь 06, 2010, 06:29:02 pm
Огромная просьба посмотреть решение на предмет ошибок...
А еще не пойму как сделать отчет как в задании.
Вложения:
4681211.dt
Отправлено: ГКС от Ноябрь 06, 2010, 07:38:14 pm
Отправлено: d1mka22091988 от Ноябрь 06, 2010, 08:54:32 pm
А так в целом как решение?
Отправлено: ГКС от Ноябрь 08, 2010, 09:12:53 am
Насчет отчета, похожий есть в примере решения, только без подразделения.
Добавлено (07.11.2010, 10:05)
---------------------------------------------
Мелкие замечания по графикам.
Имхо, в РС ГрафикиРаботы измерению ГрафикРаботы надо выставить все галочки (Ведущее, Основной отбор, Запрет незаполненных значений), а в обработке надо: Набор.Отбор.ГрафикРаботы.Установить(ГрафикРаботы); и не присваивать реквизиту График существующих строк РС значение График, ибо сказано "предусмотреть возможность работы по нескольким графикам"
Добавлено (07.11.2010, 13:38)
---------------------------------------------
Пока вижу два упущения:
В РР ОсновныеНачисления у реквизита ГрафикРаботы не указана "Связь с графиком".
В Документе про командировку не указан график работы.
Добавлено (07.11.2010, 14:31)
---------------------------------------------
Посмотрел отчет. ИМХО:
Надо в запрос добавить ДопНачисления (ОБЪЕДИНИТЬ ВСЕ), ввести параметры (Начало, Окончание).
Группировки и формат периода приблизительно как не скриншоте.
Прошу прощения за медлительность - читаю всякую историческую дребедень.
Добавлено (07.11.2010, 14:48)
---------------------------------------------
упустил в группировку Сотрудник надо добавить группировку ВидРасчета
Добавлено (07.11.2010, 14:53)
---------------------------------------------
Чтобы колонки были как в задании надо "Расположение полей группировок" - "Отдельно", можно поиграться и с другими настройками.
Добавлено (07.11.2010, 15:02)
---------------------------------------------
ИМХО: не совсем правильно, что оклад заполняется в форме. Если изменили оклад и перепровели документ он посчитает по старому окладу. Не достал еще замечаниями? Сам пытаюсь готовиться к экзамену.
Добавлено (08.11.2010, 09:12)
---------------------------------------------
еще: "количество рабочих часов" - это, скорее, норма чем факт
Отправлено: neskil от Ноябрь 10, 2010, 07:31:11 am
Вложения:
3.1.dt
Отправлено: ut2k5 от Ноябрь 11, 2010, 09:09:20 pm
Code
Запись.ПериодРегистрации=ПериодРегистрации;
Code
Запрос.УстановитьПараметр("ПериодРегистрации",Регистратор.ПериодРегистрации);
Предлагаю ваще из запроса убрать условие на ПериодРегистрации, достаточно &Регистратор..., к тому же переопредели форму документа и сделай там так, чтобы Периодрегистрации всегда выставлялся на начало месяца
но у тебя там много других ошибок, к примеру "Премия" однозначно в ДополнительныеНачисления иначе будет вот такой результат: "использование периода действия для ВР, не нуждающихс в нем", это сразу -1,5 бала... на экзамене
Добавлено (11.11.2010, 21:09)
---------------------------------------------
и где вот это: "первоначально значение оклада ... берется на начало расчетного периода"?, ты решил упростить решение путем задания размера в документе, еще минус бал
Отправлено: tell от Ноябрь 12, 2010, 05:07:51 pm
з.ы. нужна здоровая критика
Вложения:
3.01.dt
Отправлено: tell от Ноябрь 12, 2010, 10:11:19 pm
исправил
Вложения:
1842887.dt
Отправлено: tell от Ноябрь 15, 2010, 02:29:29 pm
Вложения:
7873735.dt
Отправлено: AndreiPiter от Январь 10, 2011, 08:21:09 pm
Вопрос так же к тем кто оставил два плана видов расчёта. Как правильнее?
Отправлено: AndreiPiter от Январь 12, 2011, 07:39:04 pm
Добавлено (12.01.2011, 19:39)
---------------------------------------------
Что значит "Следует учесть, что данные о командировке не могут вводится задним числом."? О чем это говорит в смысле реализации?
Вложения:
AP_3.01.dt
Отправлено: Kate от Январь 13, 2011, 11:54:26 am
Quote (AndreiPiter)
Что значит "Следует учесть, что данные о командировке не могут вводится задним числом."? О чем это говорит в смысле реализации?
думаю следует сделать проверку даты документа, чтобы она не была меньше текущей, и ни в коем случае не разрешать проводить документ "задним числом". т.е. в обработке проведения принудительно вызывать отказ от проведения, в случае если необходимые условия (дата не меньше текущей) не выполняются.
Отправлено: pako_amadi от Январь 17, 2011, 11:25:06 pm
Kate, AndreiPiter,
Думаю это значит сдесь намек на сторнирование , все всегда вводится вовремя
Отправлено: Danan от Январь 18, 2011, 01:26:18 pm
Quote (AndreiPiter)
Вопрос так же к тем кто оставил два плана видов расчёта. Как правильнее?
Нужно два ПВР, в одном пвр хранятся вр использующие периодействия, в другом не использующие. Более подробно об этом можно узнать литературе и вебинаре П.Чистова по СПР.
Отправлено: pako_amadi от Январь 19, 2011, 12:41:08 am
Вложения:
7404013.dt
Отправлено: Matcoder от Январь 19, 2011, 01:25:00 pm
Quote (pako_amadi)
Что значит "Следует учесть, что данные о командировке не могут вводится задним числом."? О чем это говорит в смысле реализации?
По-моему это намек на то, что получать данные для расчета командировки и оклада можно одним запросом. Поскольку их периоды не будут пересекаться.
Отправлено: SergTH000 от Январь 20, 2011, 12:49:08 am
Quote
Что значит "Следует учесть, что данные о командировке не могут вводится задним числом."? О чем это говорит в смысле реализации?
могут вводиться - нужно сделать сторно-записи
не могут - сторно-записи делать не нужно...
Отправлено: Matcoder от Январь 20, 2011, 10:15:00 am
А если про заднее число вообще упоминания нет? Тогда нужно делать сторно или нет?
Отправлено: SergTH000 от Январь 20, 2011, 10:51:41 am
Quote
А если про заднее число вообще упоминания нет? Тогда нужно делать сторно или нет?
Если год высокосный и в пятницу 13 полнолуние тогда точно надо.
Ну я же не ясновидящая=)))) У экзаменатора уточнять надо)
Отправлено: Danan от Январь 20, 2011, 10:56:56 am
Вложения:
Task_3_1.dt
Отправлено: SergTH000 от Январь 20, 2011, 11:41:41 am
1. База для командировки - сумма ВСЕХ начислений, т.е. и командировки тоже.
2.Не понял зачем тебе ресурс ОтработаноЧасов в РР ОсновныеНачисления? Часовая ставка командировки- сумма всех начислений делить на кол-во РАБОЧИХ часов - те ЗначениеБазовыйПериод, этот ресурс нужен если бы было делить на количество отработанных часов.
3.
Quote
Движения.ОсновныеНачисления.Записывать=Истина;
Движения.ОсновныеНачисления.Записать();
Движения.ДополнительныеНачисления.Записать();
ПроведениеРасчетов.РассчитатьОсновныеНачисления(Движения.ОсновныеНачисления);
ПроведениеРасчетов.РассчитатьДополнительныеНачисления(Движения.ДополнительныеНачисления);
Движения.ОсновныеНачисления.Записать();
Движения.ДополнительныеНачисления.Записать();
ПроведениеРасчетов.РассчитатьОсновныеНачисления(Движения.ОсновныеНачисления);
ПроведениеРасчетов.РассчитатьДополнительныеНачисления(Движения.ДополнительныеНачисления);
Вот это
Quote
Движения.ОсновныеНачисления.Записывать=Истина
означает что после завершения обработки проведения движения запишутся в регистр
Quote
Движения.ОсновныеНачисления.Записать();
Принудительно записываешь движения, флаг записывать не сброшен движения опять запишутся.
4. Есть еще два совета:
-делайте отдельные ТЧ документа Начисление на каждый ПВР, колонки у них различаются, проще тестировать и нагляднее. У меня на экзамене было даже три ТЧ Основные, Дополнительные и Удержания ничего не придрались.
-Твой запрос в общем модуле абсолютно нечитабелен и работать он будет дольше чем два разных запроса при расчете основных и дополнительных начислений.
Отправлено: Danan от Январь 20, 2011, 02:48:02 pm
1) Ты имеешь ввиду ,что вид расчета командировка собирает базу по саму себе, иными словами в тч базовые у этого вида расчета указаны все виды расчета, включая его самого?
2) Наверно ты прав.
3) Химичил с кодом забыл убрать.
4)Основные и Дополнительные начисления рассчитываются в разных процедурах.
Запрос по основным начисления строится так:
Если в наборе записей есть командировка то идет обращение к таблице ДанныеГрафика и базовой таблице. Если в наборе записей только оклад то обращение только к таблице ДанныеГрафика.
Все нормально читается. В любом случае финальный текст запроса можно прочитать в отладчике.
Спс за критику, выводы сделал, мб выложу переделанную базу.
А ПВР и РР правильно настроил?
Отправлено: SergTH000 от Январь 21, 2011, 07:08:42 pm
1. Да, командировка входит в свою базу.
2. Точно тебе говорю)
4. Это советы, проще сделать два запроса, один по основным начислениям - ДанныеГрафика + БазаОсн+БазаДоп и по доп - только из одной табл. - БазаОсн, так проще, твой текст конструктором нельзя открыть..
И вообще если такой целью задаться можно и все виды расчета в одной процедуре рассчитывать - нафигачить там если, если, если....Их в разных процедурах расчитывают именно потому что запросы разные. Ну вообщем как знаешь.
РР, ПВР Настроил правильно.
Отправлено: Danan от Январь 22, 2011, 09:29:25 am
По 4 пункту: Видать вправду текст не очень читабельный, ты кажется мою идею не понял. И так две процедуры, для расчета одного НабораЗаписей своя процедура со своим запросом.
При расчете осн начислений цель ставил такую:
Немного облегчить процедуру расчета осн начислений. Не хотелось строить отдельные запросы на
оклад и командировка. Для расчета им нужна таблица ДанныеГрафика, а для расчета командировки еще и базовые таблицы. Поэтому запрос для осн начислений всегда строится по ДанныеГрафика и если в НабореЗаписей есть командировка то подтягиваются базовые таблицы.
Однако спасибо за совет, если ему следовать можно выиграть время.
Отправлено: detec от Январь 25, 2011, 11:08:29 am
Знаю, что это не соответствует теории, но на практике, в типовых конфигурациях, делается примерно так же.
Вложения:
1Cv8_detec_3.01.dt
Отправлено: Danan от Февраль 18, 2011, 01:33:06 pm
Например начисляют оклад с 1 числа по 31 сотруднику.
Этого же сотрудника отправляют с 10 по 20 в командировку.
Командировка вытесняет оклад за этот интервал времени и у оклада остаются интервалы с 1 по 9 и с 21 по 31. Фактическим периодом действия оклада будут являться эти два интервала. Или если получить данные графика ЗначениеФактическийПериодДействия=21( если график работы 7 дневка).
Потому за 21 день должен начисляться оклад, который составит базу расчета для премии.
Допустим ставка оклада 10000, процент премии 10
Оклад =21*10000/31=6774,19;
Премия=6774,19*10/100=677.41;
И еще нужно рассчитать командировку по условиям задачи.
Для этого нужно должным образом настроить графики работы, планы видов расчета и их виды расчета , регистры расчета и тд. В частности в тч вытесняющие у оклада должен быть указан вид расчета командировка.
Отправлено: Danan от Февраль 21, 2011, 01:09:53 pm
Если хочешь рассчитывать оклад с учетом изменений ставки по окладу в течении месяца, то можно для примера посмотреть решение задачи 3.28 от SINISTER_STAR, или мое решение этой же задачи в теме Билит № 2. В обоих случаях в модуле документа НачислениеЗарплаты можно увидеть как формируются записи РР с учетом изменений тарифных ставок в расчетном периоде(месяце).
Отправлено: SergTH000 от Февраль 25, 2011, 01:30:48 am
1.
Quote
Зачем в некоторых решениях используются реальные таблицы РР и соединяются с виртуальными (хотя вроде все необходимые данные есть в виртуальных табл)?
Мое мнение - использовать реальные таблицы в задачах по СПР не нужно. Но нужно учитывать, что в виртуальных таблицах может не быть записей. Например в вирт табл. ДанныеГрафика есть все что и в реал, а если данных нет, то график не заполнен ну и рассчитывать тогда нечего, поэтому ее можно соединять Левыми соединениями с остальными вирт таблицами.
Другой пример - при расчете доп. начислений есть вид расчета в базу которого входят виды и из Основых и Дополнительных начислений. Вот тут может возникнуть ситуация, изначально не известно вдруг в какой то одной таблице нет записей, тогда нужно брать номер из другой. То есть выбирать нужно например так - IsNULL(БазаОснНачисления.НомерСтроки, БазаДопНачисления.НомерСтроки) и соединять полным соединением.
2.
Quote
Необходимо ли делать проверку на дату начала и окончания для видов расчета???? Или это имеется в виду что не заморачиваться по этому поводу???
Именно не заморачиваться.
3.
Quote
Также нужно ли очищать записи в начале документа так как делали в оперативном и бух учете (Движения.ОсновныеНачисления.Записать();) ????
Отправлено: Alejandro_m от Июнь 08, 2011, 11:07:01 pm
ну типа так что ли:
ВЫБРАТЬ
ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия,
ОсновныеНачисленияДанныеГрафика.Сотрудник,
ОсновныеНачисленияДанныеГра фика.ПериодДействия
ИЗ
РегистрРасчета.ОсновныеНачисления.ДанныеГрафика() КАК ОсновныеНачисленияДанныеГрафика
ГДЕ
ОсновныеНачисленияДанныеГрафика.Сотрудник = &Сотрудник
И ОсновныеНачисленияДанныеГрафика.ПериодДействия МЕЖДУ &НачалоПериодаДействия И &КонецПериодДействия
Судя по тому как это делают в типовых конфигурациях - нужно добавлять еще один ресурс - норма часов - т.е. учитывать сколько сотрудник должен бы был отработать в данном периоде. хотя в данной задаче не понятно - предположим он работает по графику ВТ,СР,ЧТ а командировку ему сказано начислять по пятидневке. в этом случае количество "рабочих" часов сумма всех рабочих часов по графику ВТ,СР,ЧТ или нет?
Отправлено: Gyd от Июнь 09, 2011, 09:23:42 am
Quote (Alejandro_m)
в этом случае количество "рабочих" часов сумма всех рабочих часов по графику ВТ,СР,ЧТ или нет?
Количество рабочих часов у вас будет определяться по тем записям которые уже сделаны, в этих записях же указаны графики по которым работал сотрудник. Допустим в первом месяце - ВТ, СР, ЧТ, во втором - пятидневка, соответственно за первый месяц посчитается количество рабочих часов по графику ВТ,СР,ЧТ, а за второй - по пятидневке. Посмотрите уже решенные задачи как в них это реализовано.
Отправлено: Gulf_Stream от Июнь 09, 2011, 04:26:07 pm
Вложения:
3.01_Gulf_Strea.dt
Отправлено: Alejandro_m от Июнь 09, 2011, 10:03:57 pm
Quote (Gyd)
Посмотрите уже решенные задачи как в них это реализовано.
Можете подсказать какой именно пример? (что бы не учиться тому как делать не нужно)
Отправлено: Gyd от Июнь 10, 2011, 10:37:04 am
Quote (Alejandro_m)
Можете подсказать какой именно пример?
Ну если вам не лень, то гляньте все базы, посмотрите насколько разными могут быть пути решения
лично мне больше всего понравился вариант AndreiPiter, хотя пока не могу сказать всё там правильно или нет, но решение само по себе интересное и простое.
Отправлено: Slimper от Июнь 16, 2011, 02:10:18 pm
Посмотрел выложенные решения, у всех оклад берется на ПериодРегистрации или НачалоМесяца(ПериодРегистрации), те если начислим майский оклад в июне, то оклад он возьмет июньский
И ещё, кто-нибудь может обосновать, почему для Подразделения народ использует измерение регистра, а не реквизит?
Вложения:
3_1_Slimper.dt
Отправлено: Gyd от Июнь 16, 2011, 04:01:08 pm
Quote (Slimper)
И ещё, кто-нибудь может обосновать, почему для Подразделения народ использует измерение регистра, а не реквизит?
Наверное для того чтобы можно было проще производить отбор (и последующую выборку) по нужному подразделению, например при установке параметров виртуальной таблицы. Ну и подразделение это все таки не вспомогательная информация, а один из разрезов учета, подразумевается что один и тот же сотрудник может работать в разных подразделениях, значит нужны отдельные записи по каждому подразделению.
Добавлено (16.06.2011, 16:01)
---------------------------------------------
Quote (Slimper)
Посмотрел выложенные решения, у всех оклад берется на ПериодРегистрации или НачалоМесяца(ПериодРегистрации), те если начислим майский оклад в июне, то оклад он возьмет июньский
Согласен. Просто многие наверное подумали что документ вводится в том месяце за который вводятся данные.
Отправлено: Slimper от Июнь 16, 2011, 04:22:06 pm
Quote (Gyd)
Наверное для того чтобы можно было проще производить отбор (и последующую выборку) по нужному подразделению, например при установке параметров виртуальной таблицы. Ну и подразделение это все таки не вспомогательная информация, а один из разрезов учета, подразумевается что один и тот же сотрудник может работать в разных подразделениях, значит нужны отдельные записи по каждому подразделению.
Это понятно, но в условии задачи про подразделение нет ни слова (те отбор и выборка не обязательны), оно присутствует только в отчете. Получается построив отчет по физ или виртуальной таблице, где бы ни было подразделение, в реквизите или измерении, результат получится одинаковый. С другой стороны как пишут тут, отвечая на этот вопрос
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=545035#545035
"Измерение - это признак детализации итоговых данных, накапливаемых в ресурсах регистра. Отчет - средство отображения этих итоговых данных. "
Но! В этой задаче, в этой же роли может выступать и реквизит, так что фиг его знает как правильно
Отправлено: Gyd от Июнь 17, 2011, 03:30:21 pm
Quote (Slimper)
Но! В этой задаче, в этой же роли может выступать и реквизит, так что фиг его знает как правильно
Думаю вот это был правильный ответ:
Quote (Белоусов Павел, 1С)
Не снизит. Вопрос только: почему реквизит, а м.б. измерение? Поэтому, необходимо подумать: чем измерение регистра отличается от реквизита?
Отправлено: valdu от Июнь 24, 2011, 12:46:13 pm
Или с этим не надо заморачиваться, а просто всех обсчитывать по пятидневке. Графики сделать просто, чтобы выполнить требование условия задачи.
Отправлено: Lukashov_as от Июнь 24, 2011, 03:29:57 pm
1) по условию : "Часы, проведенные в командировке, определяются по пятидневному графику работы.", т.е. можно предположить
что в условии говориться обо всех часах! и о часах "Часы, проведенные в командировке" и о часах "деленная на количество рабочих часов в двух предыдущих месяцах" вне зависимости от графика(ов) по которому работал сотрудник 2 предыдущих месяца
я думаю этот вопрос, лучше уточнить на devtrainingforum.v8.1c.ru/forum/
2)Логичнее все таки брать часы двух предыдущих месяцев по тем графикам по которым работал сотрудник(потому как если сотрудник отработал месяц по 1 через 3 и получил соответствующую зп а мы ему ЗП по графику 1/3 разделим на 5 раб дней получиться какая то глупая цифра)
Тогда тут скорее всего необходимо ввести ресурс так же как и для отработанных часов
при расчете оклада записываем
Запись.ОтработанныеЧасы = ЗначениеФактическийПериодДействия
Запись.РабочиеЧасы = ЗначениеПериодДействия
и уже по РабочиеЧасыБаза будем определять количество РАБОЧИХ часов, по ОтработанныеЧасыБаза количество ОТРАБОТАННЫХ часов
ввиду того что из 2х предыдущих месяцев сотрудник мог поработать один месяц по 2х дневке а второй по шестидневке, то засунуть РабочиеЧасы в ресурс думаю оправданно
но тут есть маленькая засада, если в одном месяце ввести сотруднику 2 раза оклад то РабочиеЧасы за двоится, поскольку ЗначениеПериодДействия будет одинаковым для обоих расчетов в одном месяце это количество часов рабочих во всем месяце, можно конечно проверить в первый или не в первый раз начисляется оклад в этом месяце, или можно сослаться на условие что сотруднику начисляется оклад ежемесячно 1 раз, но серавно как то не по человечески
Коллеги кто что думает по сему вопросу?
я этот вопрос поднимал тут http://forum.chistov.pro/index.php?topic=1525.msg1#msg1 но честно так до конца и не понял как тут лучше поступить
valdu, закинь этот вопрос на девтренинг. будет результат отпишись, попроси Белоусова уточнить по варианту 1, можно ли так трактовать условия
Отправлено: Gyd от Июнь 24, 2011, 04:40:20 pm
Quote (Lukashov_as)
Коллеги кто что думает по сему вопросу?
я этот вопрос поднимал тут http://forum.chistov.pro/index.php?topic=1525.msg1#msg1 но честно так до конца и не понял как тут лучше поступить
я этот вопрос поднимал тут http://forum.chistov.pro/index.php?topic=1525.msg1#msg1 но честно так до конца и не понял как тут лучше поступить
я вам ответил в этой ветке, но видимо ответил непонятно.
Quote (Lukashov_as)
Часы, проведенные в командировке, определяются по пятидневному графику работы."
Сотрудник поехал в командировку. Работал в четверг - 9 часов, в пятницу - 10 часов, в субботу - 4 часа. Определяем часы по пятидневке - четверг -8, пятница -8, суббота -0 часов.
Отправлено: Lukashov_as от Июнь 24, 2011, 04:58:13 pm
как взять проведенные фактически часы в командировке по пятидневке оно то понятно абсолютно, при формировании движения мы график работы сделаем пятидневку, при расчете возмем ЗначениеФактическийПериодДействия, и получим проведенные часы по пятидневке
а теперь попробую объяснить что не понятно
присвоив командировке график работы = пятидневка, у нас получиться что
ЗначениеПериодДействия
ЗначениеФактическийПериодДействия
ЗначениеПериодРегистрации
и!!!!!!
ЗначениеБазовыйПериод
будут считаться по пятидневке!
базовый период у нас 2 месяца, предположим, первый месяц чел работал 2 через 2, второй месяц работал по шести дневке, и нам для расчета необходимо узнать количество РАБОЧИХ дней в 2х предыдущих месяцах
т.е. это количество рабочих часовпри графике 2 через 2 + количество рабочих часовв шестидневке
вот именно эти рабочие дни надо вытащить!!!! а по пятидневке то ясно понятно тут вопросов нет, и ЗначениеБазовыйПериод будет по пятидневке
вот тут реально не понимаю
задачу прикрепленную увидел после того как запостил вопрос. вечером гляну спасибо за пример
Отправлено: Gyd от Июнь 24, 2011, 05:08:18 pm
попозже посмотрю свежим взглядом.
Отправлено: valdu от Июнь 24, 2011, 05:31:12 pm
Посмотрел ваше решение. Ввел один документ только с окладом за апрель : бельдыев - 20000
еще один за май: бельдыев - 20000. Оба с шестидневкой.
в июне документ с командировкой: опять бельдыев с 01.06 по 05.06. Вроде как 3 дня (24 часа). Результат: 2 790,70
не понял как так получилось. По моим расчетом должно быть или 2307,69 или 2727,27
Отправлено: Lukashov_as от Июнь 24, 2011, 06:10:21 pm
Отправлено: Gyd от Июнь 24, 2011, 08:17:51 pm
Quote (Lukashov_as)
куда свои вариант убрал, только добрался глянуть че как
да что-то он мне показался нерабочим, я решил убрать пока. Сам вот засомневался.
А вам в этой веточке (http://forum.chistov.pro/index.php?topic=1525.msg1#msg1) надо было возразить мне как следует, так бы и сказали: мне непонятно, объясни еще раз. Я же тоже могу ошибаться, может не заметил чего-то.
Добавлено (24.06.2011, 20:17)
---------------------------------------------
Quote (Lukashov_as)
присвоив командировке график работы = пятидневка, у нас получиться что
ЗначениеПериодДействия
ЗначениеФактическийПериодДействия
ЗначениеПериодРегистрации
и!!!!!!
ЗначениеБазовыйПериод
будут считаться по пятидневке!
ЗначениеПериодДействия
ЗначениеФактическийПериодДействия
ЗначениеПериодРегистрации
и!!!!!!
ЗначениеБазовыйПериод
будут считаться по пятидневке!
Вы абсолютно правы, я пошел по пути коллег считая что их варианты рабочие, а это оказывается не так. Плюсую
Фактические часы посчитать просто, а вот рабочие... надо подумать.
Отправлено: Lukashov_as от Июнь 24, 2011, 10:04:54 pm
это в ресурс вводить ЗначениеПериодДействия, но тут как я писал засада при двойном вводе оклада даже при разных периодах действия пусть первый раз начисляли с 01 по 12 а второй раз решили начислять с 25 по 30
суть в том что почему то не смотря на описание в проф разработке что
ЗначениеПериодДействия - это количество "дней" в периоде действия, а ЗначениеПериодРегистрации - это количество дней в периоде регистрации, на практике они равны, почему не знаю этот вопрос тоже надо разбирать!
и получится если мы сотруднику на числим в одном месяце 2 раза оклад у нас за двоится количество дней РАБОЧИХ, это получается при расчете надо смотреть а не вносился ли оклад уже в этом периоде регистрации при этом графике работы
и главное посчитать именно РАБОЧИЕ в базе при возможности работы сотрудником по разным графикам работы при том что сам расчет считается по пятидневке(при неком определенно заданном графике работы), а не ОТРАБОТАННЫЕ, отработанные все просто вносим в ресурс ОтработанныеЧасы ЗначениеФактическийПериод, а вот РАБОЧИЕ!!!!
можно сделать предположение что начисляется только раз в периоде регистрации конечно, тогда 2й ввод исключается
коллеги спецы присоединитесь к вопросу, очень интересно как здесь выкрутится эффективно
Отправлено: Gyd от Июнь 25, 2011, 08:02:46 am
1- период, июнь, (рабочих - 192, отработано фактически - 144):
док. от 30.06 - оклад с 1 по 15 - по шестидневке(рабочих 104, отработано фактически - 56)
/-----------/ - оклад с 16 по 30 - по пятидневке(рабочих 88, отработано фактически - 88)
док. от 15.06 - больничный с 6 по 12
2- период, июль, (рабочих - 208, отработано фактически - 168):
док. от 31.07 - оклад с 1 по 31 - по шестидневке(рабочих 208, отработано фактически - 168)
док. от 21.07 - больничный с 15 по 20
ИТОГО: рабочих часов за 2 периода - 400, можно увидеть в док. от 30.08 (командировка). Вроде работает
Вложения:
3_1_Gyd.dt
Отправлено: Lukashov_as от Июнь 25, 2011, 08:19:36 pm
сижу не вгоняю как оно так
У оклада нет базовых видов расчета, при этом ты вгоняешь базовый период окладу равный периоду действия
и получаешь
Стр.РабочиеЧасы = Выборка.ВсеЧасыЗаБазовыйПериод;
вот же блин финт ушами
я так понимаю это ты так извратился потому что вопреки справки ЗначениеПериодДействия возвращает все часы за период регистрации а не только часы за период действия
мне интересно это глюк или фича или я что то не понимаю
то что
ЗначениеПериодДействия = ЗначениеПериодРегистрации
а вообще красяво получилось
Отправлено: Gyd от Июнь 25, 2011, 09:45:51 pm
Quote (Lukashov_as)
ЗначениеПериодДействия возвращает все часы за период регистрации а не только часы за период действия
точнее сказать за период указанный в поле Периодичность регистра расчета.
Quote (Lukashov_as)
а вообще красяво получилось
сенкс
Подведем итоги:
ЗначениеПериодДействия - период указанный в настройках регистра (не важно какие вы даты запишите в ПериодДействияНачало/ПериодДействияКонец).
ЗначениеФактическийПериодДействия - фактически отработанный период (зависит от графика), период между ПериодДействияНачало/ПериодДействияКонец..
ЗначениеБазовыйПериод - период между БазовыйПериодНачало и БазовыйПериодКонец.
Отправлено: Alexf от Июль 01, 2011, 09:58:46 pm
Отправлено: Lukashov_as от Июль 02, 2011, 11:46:30 am
с одной стороны в каких-то задачах написано РАБОЧИЕ дни в каких-то ОТРАБОТАННЫЕ, складывается впечатление что в это слово вкладывается смысл.
но если задуматься то получается полная бессмыслица, если человек отработал в месяце только один день а остальные проболел или еще чего, то получится мы поделим начисленный оклад за один день на дни всего месяца, как то не по человечески.
Но как вариант вычисления РАБОЧИХ дней глянь у Gyd, забавно придумал как считать рабочие дни
Добавлено (02.07.2011, 11:46)
---------------------------------------------
получишь ответ, поделись здесь, вопрос интересный
Отправлено: metanal от Июль 02, 2011, 02:06:46 pm
Вложения:
3.1_metanal.dt
Отправлено: 4ekuct25 от Июль 20, 2011, 12:47:12 pm
Получается как Lukashov_as говорил:
Quote (Lukashov_as)
если человек отработал в месяце только один день а остальные проболел или еще чего, то получится мы поделим начисленный оклад за один день на дни всего месяца
Отправлено: Gyd от Июль 22, 2011, 11:39:43 am
Quote (4ekuct25)
Могу ошибаться, но Gyd ВсеНачисленияЗаБазовыйПериод делит на РабочиеЧасыБаза, а надо на ЧасовБаза.
Получается как Lukashov_as говорил:
если человек отработал в месяце только один день а остальные проболел или еще чего, то получится мы поделим начисленный оклад за один день на дни всего месяца
Получается как Lukashov_as говорил:
если человек отработал в месяце только один день а остальные проболел или еще чего, то получится мы поделим начисленный оклад за один день на дни всего месяца
Не соглашусь. По условию задачи рабочие часы - это не фактически отработанные часы.
Code
Часовая ставка рассчитывается как начальное значение оклада, деленное на количество рабочих часов в том же периоде, что и фактически отработанные часы.
Рассмотрим несколько вариантов:
1. Сотруднику ввели начисление за весь месяц и он отработал весь месяц. С 01.06 по 30.06 программа посчитает 192 рабочих часа. Начислено будет за 192 часа. Командировочные будут обычными (назовём это так).
2. Сотруднику ввели начисление за весь месяц, но отработал он фактически один день. Остальные прогулял. С 01.06 по 30.06 программа посчитает 192 рабочих часа. Начислено будет всего за 8 часов. Командировочные будут маленькие, типа сам виноват.
3. Сотруднику ввели начисление за весь месяц, но отработал он фактически один день. Остальные болел. С 01.06 по 30.06 программа посчитает 192 рабочих часа. Начисления за месяц сложатся из: за 8 часов + больничные за остальной месяц. Командировочные будут несколько меньше чем обычно.
4. Сотруднику ввели начисление за весь месяц, но отработал он фактически один день. Остальные дни был в отпуске. С 01.06 по 30.06 программа посчитает 192 рабочих часа. Начисления за месяц сложатся из: за 8 часов + отпускные. Командировочные будут такими же или немного больше/меньше чем обычно.
5. Сотруднику ввели начисление за весь месяц, но отработал он фактически один день. Остальные дни был в командировке. С 01.06 по 30.06 программа посчитает 192 рабочих часа. Начисления за месяц сложатся из: за 8 часов + командировочные. Командировочные будут немного больше чем обычно.
6. Сотрудник отработал один день, потому что был принят в последний день месяца. С 30.06 по 30.06 программа посчитает 8 рабочих часов, начисление будет тоже за 8 часов. Командировочные будут обычными.
В общем, если вы вводите сотруднику оклад то указываете период который он работал (должен отработать). Соответственно получаете планируемые (рабочие) часы. А если сотрудник по каким-то причинам отклонился от этих часов (прогул, болезнь, отпуск, командировка или что-то еще), то исходя из этого будут определяться его командировочные.
Отправлено: vvvlad85 от Август 13, 2011, 03:05:11 pm
Добавлено (13.08.2011, 15:05)
---------------------------------------------
Имеется в виду под каждым периодом пишется
Отправлено: Данияр от Август 13, 2011, 10:38:51 pm
В схеме компоновки данных на закладке выбранные поля, вызвать контекстное меню любого выбранного поля, выбрать пункт "установить заголовок", в поле ввода вести пробел и нажать ок.
Отправлено: crabzzy от Сентябрь 09, 2011, 04:44:12 pm
Скоро свой выложу.
Отправлено: chilli от Октябрь 01, 2011, 03:24:48 pm
Вложения:
3_1_chilli.dt
Отправлено: DoctorRoza от Октябрь 24, 2011, 10:00:09 pm
Отправлено: Gyd от Октябрь 25, 2011, 09:29:43 am
Quote (DoctorRoza)
Gyd, Скажите, а зачем Вы в своем решении рассчитываете больничный?
Не обращайте внимания
тренировался наверное. Quote (DoctorRoza)
Это значит, не будет сторно-записей?
Да.
Отправлено: mkanaev от Октябрь 25, 2011, 12:39:24 pm
Quote
Следует учесть, что данные о командировке не могут вводиться в систему задним числом? Это значит, не будет сторно-записей?
Это значит надо выдавать ошибку когда пользователь пытается ввести данные задним числом, вот если бы было написанно "Можно считать, что данные о командировке не могут вводиться в систему задним числом " тогда можно просто забить на это предложение и юзать механизм дополнений...
Отправлено: DoctorRoza от Октябрь 25, 2011, 08:38:48 pm
Запрос.УстановитьПараметр("Рег", Ссылка);
Запрос.УстановитьПараметр("НаДату", НачалоМесяца(Ссылка.Дата));
Запрос.УстановитьПараметр("Сотрудники", МасССотрудниками);
Запрос.УстановитьПараметр("Подразделения", МасСПодразделениями);
А зачем передавать Сотрудников и подразделение, если есть ограничение по ссылке? Как быть?
///////////////
И еще, в данной задаче, если правильно понял, в принципе не имеет значение последовательность расчета. Поэтому, Вы выборку просто обходите, а уже в зависимости от вида расчета применяете конкретный алгоритм. Так ли?
///////////////
И вот еще, для создания отчета, Вы используете реальные таблицы Осн. и доп. начислений. Это нормально? В книжках с желтыми обложками и непонятной литерой "1С" .. :)) .. написано, что нужно использовать виртуальные таблицы. Я посмотрел пример решения из сборника, там тоже самое. Как Быть? Извините, много вопросов .. разбираюсь ..
Отправлено: DoctorRoza от Октябрь 26, 2011, 09:13:28 pm
Вложения:
doctorRoza_3_1.dt
Отправлено: Gyd от Октябрь 27, 2011, 11:24:47 am
Quote (mkanaev)
- Следует учесть, что данные о командировке не могут вводиться в систему задним числом?...
- "Можно считать, что данные о командировке не могут вводиться в систему задним числом "...
- "Можно считать, что данные о командировке не могут вводиться в систему задним числом "...
Несильно заметная разница в формулировке
Quote (DoctorRoza)
А зачем передавать Сотрудников и подразделение, если есть ограничение по ссылке? Как быть?
А это для РС отбор. Код:
Code
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках.СрезПоследних(
| &НаДату,
| Сотрудник В (&Сотрудники)
| И Подразделение В (&Подразделения))
| &НаДату,
| Сотрудник В (&Сотрудники)
| И Подразделение В (&Подразделения))
Quote (DoctorRoza)
И еще, в данной задаче, если правильно понял, в принципе не имеет значение последовательность расчета. Поэтому, Вы выборку просто обходите, а уже в зависимости от вида расчета применяете конкретный алгоритм. Так ли?
Насколько я понял, в этих задачах последовательность расчета особого значения не имеет. Видов расчетов не так много и приоритеты в расчетах использовать не нужно. Достаточно рассчитать основные, а потом дополнительные и удержания. В этом случае они "выстроятся" на оси времени в нужной последовательности.
Quote (DoctorRoza)
И вот еще, для создания отчета, Вы используете реальные таблицы Осн. и доп. начислений.
Думаю вы правы, надо будет попробовать взять виртуальные таблицы, с базой например (Дополнительные.БазаОсновные).
Quote (DoctorRoza)
Извините, много вопросов .. разбираюсь ..
Да ничего
я потом к вам с вопросами по оперучету буду приставать Quote (DoctorRoza)
Посмотрите решение
- Набор записей думаю проще передать в общий модуль чем читать его.
- Вот это: Запись = НаборЗаписей[Выборка.НомерСтроки - 1]; - не рекомендуют использовать. Типа индексы могут быть разными в разных СУБД. Лучше использовать метод НайтиСледующий().
- по мелочи: Выборка.Параметр * Выборка.ЧасовФакт / Выборка.ЧасовНорма - здесь стоит проверить Выборка.ЧасовНорма на 0. Через ?(....=0, 0, ....).
Отправлено: Данияр от Октябрь 27, 2011, 11:53:10 am
А вот с рр, которые не используют период действия для формирования отчета я использую реальные таблицы, с базовыми таблицами у меня почему то не получается, я уже не помню по какой причине.
Quote (DoctorRoza)
Посмотрите решение .. может что не так сделал. Благодарю заранее!
1) В процедуре обработка проведения этот код лишний.
Code
Движения.ОсновныеНачисления.Записывать = Истина;
Движения.ОсновныеНачисления.Записать();
Движения.ОсновныеНачисления.Записать();
Потому что движения записываются принудительно.
2) Я так и не увидел, где у вас период регистрации приравнивается к началу месяца.
3) Я так понял что значение оклада вводится вручную в документе НачислениеЗарплаты. Судя по условиям задачи история изменения оклада должна храниться в рс и уже оттуда нужно подставлять соответствующие значения в расчет.
4) В процедуре расчета основных начислений, в запросе связь таблиц установлена не правильно. Таблицы нужно связывать по номеру строки.
5) Для командировки количество рабочих часов это ЗначениеБазовыйПериод. Судя по условиям задачи количество отработанных часов учитывать не нужно.
6)В процедурах расчета основных и доп начислений для синхронизации набора записей и выборки лучше использовать такой код:
Отбор=Новый Структура("НомерСтроки",);
Code
Для Каждого Стр из Набор Цикла
Отбор.НомерСтроки=Стр.НомерСтроки.
Если Выборка.НайтиСледующий(Отбор) Тогда
// ...
КонецЕсли;
КонецЦикла.
Отбор.НомерСтроки=Стр.НомерСтроки.
Если Выборка.НайтиСледующий(Отбор) Тогда
// ...
КонецЕсли;
КонецЦикла.
7) Я думаю что у вас отчет выводит данные не том виде. Хотя вопрос спорный.
Выложил свой вариант отчета.
Вложения:
5567000.erf
Отправлено: Gyd от Октябрь 27, 2011, 12:09:18 pm
Quote (Данияр)
2) Я так и не увидел, где у вас период регистрации приравнивается к началу месяца.
А зачем приравнивать? Он же при записи автоматом станет на начало периода, а РС в решении не используется.
Добавлено: Всё, понял. Период в параметрах виртуальной таблицы. В документе один, в запросе будет другой.
Отправлено: DoctorRoza от Октябрь 27, 2011, 08:11:36 pm
Quote (Данияр)
5) Для командировки количество рабочих часов это ЗначениеБазовыйПериод. Судя по условиям задачи количество отработанных часов учитывать не нужно.
А вот это у меня остается под сомнением. Для расчета командировки нужна база фактически отработанных часов за 2 предыдущих месяца. ЗначениеБазовыйПериод мне выдает полный период, плановое количество часов за 2 месяца .. Так что .. ИМХО .. дополнительный ресурс придется вводить!
Добавлено (27.10.2011, 20:11)
---------------------------------------------
Quote (Gyd)
- Вот это: Запись = НаборЗаписей[Выборка.НомерСтроки - 1]; - не рекомендуют использовать. Типа индексы могут быть разными в разных СУБД. Лучше использовать метод НайтиСледующий().
- по мелочи: Выборка.Параметр * Выборка.ЧасовФакт / Выборка.ЧасовНорма - здесь стоит проверить Выборка.ЧасовНорма на 0. Через ?(....=0, 0, ....).
- по мелочи: Выборка.Параметр * Выборка.ЧасовФакт / Выборка.ЧасовНорма - здесь стоит проверить Выборка.ЧасовНорма на 0. Через ?(....=0, 0, ....).
Спасибо .. учту на будущее ..
Вложения:
s6214202.jpg
Отправлено: Gyd от Октябрь 28, 2011, 10:04:58 am
Quote (DoctorRoza)
А вот это у меня остается под сомнением. Для расчета командировки нужна база фактически отработанных часов за 2 предыдущих месяца. ЗначениеБазовыйПериод мне выдает полный период, плановое количество часов за 2 месяца
Данияр прав. Нужны рабочие часы, а не отработанные.
Отправлено: DoctorRoza от Октябрь 28, 2011, 07:14:12 pm
"Часовая ставка для расчета командировки определяется как сумма всех начислений за два предыдущих месяца, деленная на количество рабочих часов в двух предыдущих месяцах .. "
Невнимательно прочитал условие .. Спасибо ..
Отправлено: Para_1987 от Ноябрь 13, 2011, 02:28:06 pm
Правильно ли я понял?
Рабочие часы - это часы, которые работник должен в идеале отработать, по плану.
Отработанные - те, что работник отработал.
В итоге, рабочих часов м.б больше чем отработанных?
И еще:
Первоначальное значение оклада может изменяться не чаще, чем один раз в день, но берется на начало расчетного периода.
Т.е необходимо хранить значение оклада в РС. А при вводе документа, нужно считывать значение оклада из регистра или позволять пользователю непосредственно указывать значение оклада? Тогда непонятно, если оклад может меняться каждый день, но берется на начало расчетного периода, зачем его вообще менять раз в день?
Правильно ли я понял, например:
1.10.11 Бельдыев, Бухгалтерия, 100 000р
2.10.11 Бельдыев, Бухгалтерия, 102 000р
3.10.11 Бельдыев, Бухгалтерия, 101 500р
А вот при расчете надо брать 100 000р
Благодарю за помощь зараннее.
Отправлено: Para_1987 от Ноябрь 13, 2011, 08:37:14 pm
Особо интересен момент про работу сотрудников по разным графикам и расчете командировки по пятидневке.
Вложения:
Para_1987_3.01.dt
Отправлено: Gyd от Ноябрь 14, 2011, 10:30:29 am
Quote (Para_1987)
Рабочие часы - это часы, которые работник должен в идеале отработать, по плану.
Отработанные - те, что работник отработал.
В итоге, рабочих часов м.б больше чем отработанных?
Отработанные - те, что работник отработал.
В итоге, рабочих часов м.б больше чем отработанных?
Да.
Quote (Para_1987)
Т.е необходимо хранить значение оклада в РС. А при вводе документа, нужно считывать значение оклада из регистра или позволять пользователю непосредственно указывать значение оклада?
Из регистра.
Quote (Para_1987)
А вот при расчете надо брать 100 000р
Да.
Quote (Para_1987)
Тогда непонятно, если оклад может меняться каждый день, но берется на начало расчетного периода, зачем его вообще менять раз в день?
Видимо проверяется умение пользоваться РС.
Отправлено: kow1976 от Апрель 09, 2012, 08:22:43 am
Спасибо за комментарии и замечания.
Остались сомнения по поводу подразделений. В измерение или реквизит.
Я так понял здесь вопрос заключается как мы будем брать среднею для командировки
если по окладу в разрезе подразделения то в измерения если окладу независимо от подразделения то реквизит.
Пример
Белдыев Бухгалтерия 1000
Белдыев Дворник 1500
Для командировки среднею. Если считаем по всем начислениям сотрудника (2500) то подразделение - можно в реквизит
Если командировка по конкретной должности сотрудника (Как дворник 1500) то подразделение только в измерение
Вложения:
kow1976_3.1.dt
Отправлено: Teriban от Май 23, 2012, 06:51:11 pm
Вобщем критикуйте
Вложения:
Teriban_301.dt
Отправлено: НачинающийВ1С от Июнь 19, 2012, 06:23:33 pm
Отправлено: Teriban от Июнь 19, 2012, 06:43:10 pm
Отправлено: НачинающийВ1С от Июнь 19, 2012, 07:32:28 pm
Quote (Teriban)
НачинающийВ1С, я может не знаю всех тонкостей работы с этой галкой, но мне кажется ответ на Ваш вопрос находится в самом вопросе.
нет конечно дословно понятно, возникает другой вопрос что тогда происходит с базовым периодом, он что складывается с периодом действия и вместе составят одну базу???
Отправлено: ssserg от Июль 31, 2012, 06:09:28 pm
Дошел до начисления командировочных.
И получается интересная ситуация, что нужно как то переписать общий модуль расчета всех типов начислений и
модуль объекта документа НачислениеЗарплаты из за того, что я не вижу как Командировочные могут вписаться в уже существующий код. Делал по материалам курсов spec8.
Пожалуйста посмотрите имеющуюся конфигурацию.
Вложения:
1Cv8_try_3_01_s.dt
Отправлено: ssserg от Август 01, 2012, 05:38:46 pm
Вложения:
try2.dt
Отправлено: kow1976 от Август 01, 2012, 08:25:34 pm
Поменяйте таблицу на Дополнительные начисления
ЕСТЬNULL(ДопНачисленияБазаОсновныеНачисления.СуммаБаза, 0) КАК Сумма
Отправлено: ssserg от Август 02, 2012, 07:28:47 am
Отправлено: kow1976 от Август 02, 2012, 08:24:39 am
Правой клавишей и заменить таблицу.
Если я правильно понял проблему.
Вложения:
s9289849.jpg
Отправлено: ssserg от Август 02, 2012, 10:21:03 am
Спасибо, разобрался.
Действительно, нужно брать ЕСТЬNULL(ДопНачисленияБазаОсновныеНачисления.СуммаБаза, 0)
Добавлено (02.08.2012, 10:21)
---------------------------------------------
Теперь другая проблема - не могу получить информацию по начисленным премиям за последние 2 месяца. Это нужно для расчета командировочных по всем начислениям.
По окладу всё рассчитывается идеально, а информация по премиям не хочет браться не из одной из таблиц.
Как мне кажется, то оно должно браться так:
ОсновныеНачисленияБазаДопНачисления.СуммаБаза т.е. в общем виде
<Имя регистра>База<Имя базового регистра>.<ИмяРесурса>База
Разобрался, в модуле документа в цикле доп начислений
Запись.ПериодРегистрации = Дата;
сменил на
Запись.ПериодРегистрации = ПериодРегистрации;
Отправлено: Lazio от Август 02, 2012, 11:51:45 am
Добавлено (02.08.2012, 11:51)
---------------------------------------------
И во многих решениях есть конструкция Для Каждого из ОсновныеНачисления и т д. Так что лучше запрос или так?
Отправлено: kow1976 от Август 02, 2012, 12:06:58 pm
В модуле документа смените дату на ПериодРегистрации
Code
Для каждого Стр Из ДопНачисления Цикл
Запись = Движения.ДопНачисления.Добавить();
ЗаполнитьЗначенияСвойств(Запись, Стр);
Запись.ПериодРегистрации = Дата;
Запись = Движения.ДопНачисления.Добавить();
ЗаполнитьЗначенияСвойств(Запись, Стр);
Запись.ПериодРегистрации = Дата;
Отправлено: ssserg от Август 02, 2012, 12:35:54 pm
Отправлено: pochtaelmira от Август 25, 2012, 09:31:01 pm
Отправлено: ДимокШ от Август 25, 2012, 10:16:50 pm
Давайте подытожим. Есть моменты в решении задачи, которые каждый пишет сам по-своему. А есть моменты которые должны быть сделаны одинаково. Думаю что одинаково должно быть выполнено следующее:
Итак, исходя из условий задачи 3.1:
Планы видов расчета (ПВР):
Основные начисления - использует период действия, зависит от базы по периоду действия
Дополнительные начисления - не использует период действия, зависит от базы по периоду действия
1) Необходимо создать следующие виды расчета(ВР)
Оклад по часам - имеет период действия, т.к. сотрудник работал в месяце например 10 дней.
Премия - не имеет периода действия, т.к. начисляется как тупо % от оклада в этом месяце
Командировка - имеет период действия, т.к. сотрудник может быть в командировке несколько дней.
2) Какие ВР отнести к каким ПВР?
Оклад по часам - ПВР Основные
Командировка - ПВР Основные
Премия - ПВР - дополнительные
3) Зависимость ВР от базы?
для Премия база: Оклад по часам
для Командировки база: Оклад по часам, Премия, Командировка
4) Настройки Регистра Расчета (РР):
РР Основные начисления: флаг период действия, флаг базовый период
измерения: подразделение, сотрудник
ресурсы: результат
реквизиты: размер, график (график связан и измерением регистра сведений графики работы - график)
РР Дополнительные начисления: флаг базовый период. (флаг период действия не нужен, т.к. в этом РР только премия - которая периода действия не имеет)
По перечисленным выше пунктам у всех так? Мне кажется это имеет самое принципиальное значение.
5) А самый интересный момент - при расчете командировки.
В условии задачи написано, что "часы проведённые в командировке считаются по пятидневному графику работы".
Это значит что если сотрудник был в командировке с 1 по 7 число месяца (как раз с ПН по ВС), то оп пятидневке у него получится 8*5 = 40 часов в командировке.
В прошлом месяце сотрудник отработал
7 дней по пятидневке, т.е. 40 часов, и получил 10 000 руб.
и 7 дней по шестидневке, т.е. 48 часов и получил ещё 10 000 руб.
Итого отработал 88 часов, сумма 20 000
Часовая ставка = 20 000 / Число рабочих часов. Число рабочих часов в предыдущем месяце по пятидневке например 100, по шестидневке 120.
Вопрос - на какое количество часов нужно делить? Однозначно на РАБОЧИЕ часы. Но вот рабочие часы по какому графику???
Отправлено: Gyd от Август 26, 2012, 01:14:42 am
Про остальное время (еще 2 недели), вы не написали... Может он прогулял, может болел, а может только устроился (две недели назад от окончания месяца)... В общем из условий непонятно почему у него неполный месяц. А если рассматривать только 2 отработанных недели, то кол-во рабочих часов равно количеству отработанных.
Отправлено: ДимокШ от Август 26, 2012, 09:31:36 am
В месяце 4 недели. По 5-ти дневке 176 рабочих часов, по 6-тидневке 208 часов.
1 неделю отработал по пятидневке, 1 неделю по 6-тидневке. Остальные 2 недели не работал.
Количество рабочих часов нужное для расчёта командировки какое?
Отправлено: DoctorRoza от Август 26, 2012, 04:24:07 pm
Отправлено: Gyd от Август 27, 2012, 12:34:53 pm
Quote (ДимокШ)
В месяце 4 недели. По 5-ти дневке 176 рабочих часов, по 6-тидневке 208 часов.
1 неделю отработал по пятидневке, 1 неделю по 6-тидневке. Остальные 2 недели не работал.
Количество рабочих часов нужное для расчёта командировки какое?
1 неделю отработал по пятидневке, 1 неделю по 6-тидневке. Остальные 2 недели не работал.
Количество рабочих часов нужное для расчёта командировки какое?
Количество рабочих часов = 40 (пятидневка) + 48 (шестидневка) = 88. То есть количество рабочих равно количеству отработанных.
Тот вариант что я сначала предложил - не подходит, это я понял благодаря вопросу pochtaelmira в личку, за что ей спасибо. Предлагаю рассмотреть два варианта, один назовём "Только оклады", второй "Не только оклады":
1. "Только оклады". Сотрудник работал одну неделю по шестидневке, вторую - по пятидневке (ваш пример ДимокШ). Можно поместить рабочие часы в ресурс (РабочиеЧасы), сделать записи окладов с этим ресурсом и потом получить базу по этому ресурсу. Например, первая неделя - 01.08. - 07.08 - рабочих часов 48, вторая неделя - 08.08 - 14.08 - 40 часов. При получении базы по ресурсу РабочиеЧасы у нас просуммируются 48 и 40. Будет 88. Этот вариант есть у меня в решении задачи 3.1.
2. "Не только оклады". Например, сотрудник отработал месяц по шестидневке, а неделю был в командировке (пятидневка). Вот в этом случае получение базы через ресурс уже не подойдёт. Так как здесь будет вытеснение оклада, и явно определить сколько точно рабочих часов было по шестидневке, а сколько по пятидневке - уже не удастся. Тут нужен более сложный алгоритм расчёта... И мы приближаемся к моменту о котором сказал DoctorRoza: нужно уточнить у экзаменатора.
Отправлено: kow1976 от Август 27, 2012, 09:27:57 pm
Мне кажется это пользовательская проблема. Пусть кадровик натопчит индивидуальный график неделю пять рабочих дней неделю шесть остальные нули. И будут заданные рабочие дни.
Отправлено: Gyd от Август 28, 2012, 10:44:59 am
Quote (kow1976)
Мне кажется это пользовательская проблема.
Просто хотелось программно сделать
Отправлено: ДимокШ от Август 28, 2012, 05:17:47 pm
Отправлено: Gyd от Август 28, 2012, 05:20:30 pm
Quote (ДимокШ)
При удалённой сдаче, есть ли возможность спросить у экзаменатора?
Нет. Но можно (нужно) сделать файл с пояснениями, где кратко описываете почему вы сделали так, а не иначе. Более детально можете спросить у sv_mikh. Он делал такой файл.
Отправлено: DoctorRoza от Август 28, 2012, 05:26:23 pm
Отправлено: ДимокШ от Август 29, 2012, 08:05:00 pm
Подразделение нужно вводить как измерение Регистра расчёта?
В задаче это подразделение нигде не упоминается, кроме как в последнем отчёте.... Кто как делал на экзамене? (если конечно эта задача встречалась)
Отправлено: Gyd от Август 29, 2012, 09:02:20 pm
А сотрудник может работать в разных подразделениях одновременно? Есть и другие моменты, но это самый ключевой...
Как правило все делают измерением, если в условиях явно не сказано что он в другом подразделении работать не сможет.
Отправлено: Pavlyk от Сентябрь 09, 2012, 08:24:13 pm
Quote (Gyd)
1. "Только оклады". Сотрудник работал одну неделю по шестидневке, вторую - по пятидневке (ваш пример ДимокШ). Можно поместить рабочие часы в ресурс (РабочиеЧасы), сделать записи окладов с этим ресурсом и потом получить базу по этому ресурсу. Например, первая неделя - 01.08. - 07.08 - рабочих часов 48, вторая неделя - 08.08 - 14.08 - 40 часов. При получении базы по ресурсу РабочиеЧасы у нас просуммируются 48 и 40. Будет 88. Этот вариант есть у меня в решении задачи 3.1.
2. "Не только оклады". Например, сотрудник отработал месяц по шестидневке, а неделю был в командировке (пятидневка). Вот в этом случае получение базы через ресурс уже не подойдёт. Так как здесь будет вытеснение оклада, и явно определить сколько точно рабочих часов было по шестидневке, а сколько по пятидневке - уже не удастся. Тут нужен более сложный алгоритм расчёта... И мы приближаемся к моменту о котором сказал DoctorRoza: нужно уточнить у экзаменатора.
2. "Не только оклады". Например, сотрудник отработал месяц по шестидневке, а неделю был в командировке (пятидневка). Вот в этом случае получение базы через ресурс уже не подойдёт. Так как здесь будет вытеснение оклада, и явно определить сколько точно рабочих часов было по шестидневке, а сколько по пятидневке - уже не удастся. Тут нужен более сложный алгоритм расчёта... И мы приближаемся к моменту о котором сказал DoctorRoza: нужно уточнить у экзаменатора.
Интересно все таки как правильно рассчитывать. Я вот голову ломаю уже пару часов так и не могу сообразить как это реально реализовать....Кто нибудь знает хотя бы теоретически как это делается? В типовых пока плохо шарю, поэтому скорей всего там ничего не найду поэтому и не полез смотреть....
Заранее спасибо.
Отправлено: Pavlyk от Сентябрь 09, 2012, 09:49:43 pm
И так экспериментировал на Марте 2012 года. 01.03.12 - 15.03.12 Оклад Пятидневка 88 часов по плану, 16.03.12-31.03.12 Оклад Шестидневка 112 часов по плану, с 07.03.12-21.03.12 Командировка вытесняющая оклад (в принципе не важно по какому графику) итого командировка вытесняет 56 часов по пятидневке из периода(01.03.12 - 15.03.12) и 40 часов у шестидневке в периоде (16.03.12-31.03.12) Итого 88+112-56-40 = 104. Сделал такой запрос, беру таблицу Фактический период действия, соединяю по вхождению в период даты из РС ГрафикиРаботы и суммирую.... конечно это наверное далеко не идеальный вариант, но это первое что пришло в голову...
Вложения:
s2546448.jpg
Отправлено: Oliver от Ноябрь 19, 2012, 03:08:22 am
Вложения:
Oliver_3_1.dt
Отправлено: sima от Декабрь 06, 2012, 01:34:21 am
Quote (ДимокШ)
Действительно, неудачный пример. Приведу другой:
В месяце 4 недели. По 5-ти дневке 176 рабочих часов, по 6-тидневке 208 часов.
1 неделю отработал по пятидневке, 1 неделю по 6-тидневке. Остальные 2 недели не работал.
Количество рабочих часов нужное для расчёта командировки какое?
В месяце 4 недели. По 5-ти дневке 176 рабочих часов, по 6-тидневке 208 часов.
1 неделю отработал по пятидневке, 1 неделю по 6-тидневке. Остальные 2 недели не работал.
Количество рабочих часов нужное для расчёта командировки какое?
Quote (Gyd)
Например, сотрудник отработал месяц по шестидневке
Я вот думаю, а если в задаче явно прописано что: "Все сотрудники работают по пятидневному графику ..." - не значит ли это, что работник не может работать не по пятидневке?
А фраза: "...необходимо предусмотреть возможность работы по нескольким графикам" - обязывает нас лишь добавить соответствующий реквизит в регистры(не более)?
Quote (ДимокШ)
Подразделение нужно вводить как измерение Регистра расчёта?
Моя логика подсказывает мне, что если в задаче прямо ничего не сказано про подразделение, но оно есть в отчете, делать надо следующим образом: Добавляем реквизит "Подразделение" в справочник "ФизическиеЛица", и презамечательно выводим его в отчет. Условию мы не противоречим, отчет мы сделали. Зачем усложнять?
Отправлено: DoctorRoza от Декабрь 06, 2012, 09:52:33 am
Quote (sima)
Моя логика подсказывает мне, что если в задаче прямо ничего не сказано про подразделение, но оно есть в отчете, делать надо следующим образом: Добавляем реквизит "Подразделение" в справочник "ФизическиеЛица", и презамечательно выводим его в отчет. Условию мы не противоречим, отчет мы сделали. Зачем усложнять?
Ваша логика Вас обманывает. Если Вы откроете любую типовую конфу, то увидите, что спр. Физ. лица никаких реквизитов - подразделение не содержит. Как аргумент, если сотрудник будет переведен в др. подразделение, то что Вы будете тогда делать? Добавлять новый элемент в справочник?
Отправлено: sima от Декабрь 06, 2012, 11:54:11 am
Quote (DoctorRoza)
Ваша логика Вас обманывает. Если Вы откроете любую типовую конфу, то увидите, что спр. Физ. лица никаких реквизитов - подразделение не содержит. Как аргумент, если сотрудник будет переведен в др. подразделение, то что Вы будете тогда делать? Добавлять новый элемент в справочник?
Если сотрудник будет переведен в другое подразделение, я поменяю значение поля "Подразделение" записи таблицы "ФизическиеЛица". Вы спросите: а как же начисления? Отвечаю: в части задания, описывающей начисления, нету ни слова про подразделения. Ну если уж это не аргумент для экзаменатора... Тогда я вынужден согласиться с вами.
Правда в этом случае мне не совсем понятно, при решении задания я должен сделать то, что описано в задании, или то, что вижу, открыв типовую?
Отправлено: DoctorRoza от Декабрь 06, 2012, 02:15:36 pm
Quote (sima)
Правда в этом случае мне не совсем понятно, при решении задания я должен сделать то, что описано в задании, или то, что вижу, открыв типовую?
Типовая конфигурация - это эталон или около того, программирования в среде 1с вообще. Более конкретно тут подойдет, в качестве примера, УТ 11. Поделки "1С-Совместимо" к эталонам не относяться. На экзамене Вам нужно будет решить билет методически верно. Это избитый вопрос - про "рабочее решение" и "правильное решение", тут это обсуждалось тьма раз и ответа на него нет. Единственное, что тут можно сказать - это смотрите, как решают коллеги.
Отправлено: sima от Декабрь 06, 2012, 04:44:14 pm
Quote (DoctorRoza)
Единственное, что тут можно сказать - это смотрите, как решают коллеги.
Я стараюсь, честно. И вижу, что у коллег возникают вопросы, ответы на которые есть в тексте задания. Беда, кажется, в том, что ответы эти можно трактовать как в сторону усложнения, так и в сторону упрощения решения.
Собственно, в связи с этим мне интересно, трактовка задачи в сторону упрощения - это плюс или минус?
Добавлено (06.12.2012, 16:29)
---------------------------------------------
Quote (Gyd)
Насколько я понял, в этих задачах последовательность расчета особого значения не имеет. Видов расчетов не так много и приоритеты в расчетах использовать не нужно. Достаточно рассчитать основные, а потом дополнительные и удержания. В этом случае они "выстроятся" на оси времени в нужной последовательности.
Вот этот момент совершенно неясен.
Пример документа:
ДатаРегистрации = 01.02.12
Оклад = 01.01.12 - 31.01.12
Премия = 01.01.12 - 31.01.12
Командировка = 01.02.12 - 03.02.12
Получается что мне надо сначала посчитать Оклад, потом Премию, потом Командировку,
но Оклад и Командировка - основные начисления, а премия - дополнительные... Не могу понять, как организовывать расчет в этом случае? Как сюда прикручивать приоритет?
Добавлено (06.12.2012, 16:33)
---------------------------------------------
Quote (sima)
ДатаРегистрации = 01.02.12
Оклад = 01.01.12 - 31.01.12
Премия = 01.01.12 - 31.01.12
Командировка = 01.02.12 - 03.02.12
Оклад = 01.01.12 - 31.01.12
Премия = 01.01.12 - 31.01.12
Командировка = 01.02.12 - 03.02.12
В задании есть такая строчка: "Считать что все данные вводятся в приделах одного месяца". Значит ли это, что мой пример некорректен в данном случае?
Добавлено (06.12.2012, 16:44)
---------------------------------------------
Quote (Gyd)
Вот это: Запись = НаборЗаписей[Выборка.НомерСтроки - 1]; - не рекомендуют использовать. Типа индексы могут быть разными в разных СУБД. Лучше использовать метод НайтиСледующий().
Я правильно понял, что методологически правильнее цикл устраивать по набору движений, а затем искать в выборке, используя НайтиСледующий()?
Отправлено: Oliver от Декабрь 07, 2012, 03:22:42 am
Quote
Получается что мне надо сначала посчитать Оклад, потом Премию, потом Командировку,
Это тоже самое, только у Вас все начиления задним числом кроме командировки. На такое заморачиваться не нужно.
Quote
Значит ли это, что мой пример некорректен в данном случае?
Quote
Я правильно понял, что методологически правильнее цикл устраивать по набору движений, а затем искать в выборке, используя НайтиСледующий()
...я не согласен с DoctorRoza - что за основу решения задач к экзамену нужно брать типовые и во всём на них ровнятся. Павел Чистов - такого же мнения, в типовых решают совсем другие вопросы. Задача экзамена показать знание типовых механизмов...
Отправлено: Lazy от Декабрь 08, 2012, 01:31:49 pm
Отправлено: sima от Декабрь 09, 2012, 01:41:49 am
Quote (Lazy)
что в условии задачи показывает, что нужен табель?
Отсутствие понятия "Метод отклонений".
Quote (Lazy)
указать кто сколько рабочих часов отработал и в каких днях в командировке был
Документ "Начисление" методом отклонений:
В шапке указывается дата регистрации начисления (может быть датой документа, а может быть отдельно)
В строках табличной части указывается какому сотруднику(в каком подразделении), по какому графику, виду расчета (Оклад, командировка, премия) за какой период расчета(+базовый период опционально) какой процент(сумма) начисляется.
Добавлено (09.12.2012, 01:41)
---------------------------------------------
Могу ошибаться 
Отправлено: Oliver от Декабрь 09, 2012, 01:52:03 am
Quote
И вообще что в условии задачи показывает, что нужен табель?
Если в задании есть фраза:"начисление зарплаты ведётся методом отклонений" тогда табель точно не нужен.
Отправлено: anatoliykichuk от Январь 05, 2013, 08:41:44 pm
Прошу дать отзывы по результату решения задания 3.1 сборника (редакция 3) - см. dt-файл во вложении.
В отношение варианта решения у меня есть сомнения в части расчета командировочных: похоже, что коэффициент расчета (часы нахождения в командировке по пятидневке / фактический период действия за предыдущие два месяца) правильней было бы получать из таблицы данных графика, но я не уразумел, как этого можно добиться... - может кто-нибудь подскажет.
Павел, прошу Вас высказать свое мнение, что поможет мне лучше усвоить материал.
Вложения:
1Cv82___3.1.dt
Отправлено: anatoliykichuk от Январь 05, 2013, 08:48:54 pm
Прошу дать отзывы по результату решения задания 3.1 сборника (редакция 3) - см. dt-файл во вложении.
В отношение варианта решения у меня есть сомнения в части расчета командировочных: похоже, что коэффициент расчета (часы нахождения в командировке по пятидневке / фактический период действия за предыдущие два месяца) правильней было бы получать из таблицы данных графика, но я не уразумел, как этого можно добиться... - может кто-нибудь подскажет.
Павел, прошу Вас высказать свое мнение, что поможет мне лучше усвоить материал.
Вложения:
4612080.dt
Отправлено: alex7six от Январь 09, 2013, 08:25:10 pm
Всем спасибо за решения
Прикладываю свой вариант
Вложения:
3-1.dt
Отправлено: Oliver от Январь 11, 2013, 08:30:45 am
Отправлено: alex7six от Январь 12, 2013, 02:06:13 pm
Цитата (Oliver)
alex7six, ошибок не увидел
Задача легкая.
Спасибо, что проверил
Отправлено: mik19770727 от Январь 16, 2013, 12:23:02 pm
т.е. не используется механизм сторнирования?(не могу ввести командировку за март с периодом регистрации-апрель)?
Отправлено: sima от Январь 16, 2013, 02:00:50 pm
Цитата (mik19770727)
т.е. не используется механизм сторнирования?(не могу ввести командировку за март с периодом регистрации-апрель)?
Отправлено: mik19770727 от Январь 16, 2013, 05:39:53 pm
alex7six, посмотрел твое решение, у тебя фактические часы для расчета командировки берутся по норме
насколько я знаю ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод- это норма часов в базе, а чтобы получить факт нужно заводить ещё один ресурс с факт часами в регистре
чтобы получать РезультатБаза и ФактЧасыБаза
Отправлено: sima от Январь 16, 2013, 06:51:16 pm
Цитата (mik19770727)
ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод- это норма часов в базе
Вы правы, только тут может быть сложный случай, когда требуется узнать норму часов по базовому начислению, когда базовое начисление посчитано по другому графику.
Вот тут кажется объясняют суть: http://forum.chistov.pro/index.php?topic=468.msg9706#msg9706
Но я лично не проверял.
Отправлено: alex7six от Январь 16, 2013, 10:25:59 pm
Цитата (mik19770727)
насколько я знаю ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод- это норма часов в базе, а чтобы получить факт нужно заводить ещё один ресурс с факт часами в регистре чтобы получать РезультатБаза и ФактЧасыБаза
Отправлено: mik19770727 от Январь 17, 2013, 12:57:21 pm
Цитата (sima)
Вы правы, только тут может быть сложный случай, когда требуется узнать норму часов по базовому начислению, когда базовое начисление посчитано по другому графику.
Цитата (sima)
Вот тут кажется объясняют суть: http://forum.chistov.pro/index.php?topic=468.msg9706#msg9706
Цитата (alex7six)
Нам в этой задаче не нужно хранить ресурсом количество отработанных часов, т.к. при расчете командировки мы должны получить просто количество рабочих часов в 2х пред-х месяцах. Ресурс ОтработаноДней нужен нам был бы, если бы нам надо было получить количесство отработанных часов в 2х пред-х месяцах
Отправлено: sima от Январь 17, 2013, 01:05:55 pm
Цитата (mik19770727)
Допустим что рабочие часы это и есть нормо часы , тогда если в предыдущих 2-ух месяцах были вытеснения оклада, то мы получим заниженную дневную ставку.
Отправлено: mik19770727 от Январь 17, 2013, 01:47:25 pm
Цитата (sima)
Вытеснения не влияют на норму часов графика.
Цитата (sima)
Как вы уж потом эту норму посчитаете - вопрос к вам.
так вот если были вытеснения и мы берем часы как Норма то дневная ставка снижается в отличии от того если бы мы брали часы как факт
Отправлено: sima от Январь 17, 2013, 02:39:01 pm
Цитата (mik19770727)
так вот если были вытеснения и мы берем часы как Норма то дневная ставка снижается в отличии от того если бы мы брали часы как факт
Давайте еще раз определимся с понятиями:
Норма часов (Рабочих часов, Часов по плану) - не меняющиеся данные графика за период.
Фактически часов (Отработано часов, прогул часов, проболел часов) - фактический период действия ВР. Может быть меньше, равен или больше нормы часов. Вытесняется, сторнируется.
База - сумма ресурса регистра, учитывая вытеснения и сторно за определенный период.
Значение (оклада, процента, фикс. сума) - вводимая пользователем, или вычисляемая величина.
Считаем дневную ставку и оклад:
ДневнаяСтавка = ЗначениеОклада/Норма;
Оклад = ДневнаяСтавка*Факт;
Упрощаем:
Оклад = ЗначениеОклада/Норма*Факт;
Теперь ещё раз, в чем вопрос?
Отправлено: mik19770727 от Январь 17, 2013, 06:38:46 pm
1-ый вариант ДневнаяСтавкаБаза = База/НормаБаза
2-ой вариант ДневнаяСтавкаБаза = База/ФактБаза
Командировка = ДневнаяСтавкаБаза*ФактДнейВКомандировке
В билете 3.1 указано считать по 1-му варианту
Вопрос конечно риторический , но с точки зрения здравого смысла 1-ый вариант не имеет смысла потому что при вытеснении база может уменьшиться до суммы за один день и работал человек по факту один день , а мы ему дневную ставку посчитаем как сумма за один день разделив к примеру на 22 рабочих дня в базе и исходя из этой мизерной ставки расчитаем командировку.
Отправлено: sima от Январь 17, 2013, 10:40:47 pm
Цитата (mik19770727)
и исходя из этой мизерной ставки расчитаем командировку.
Цитата (mik19770727)
1-ый вариант ДневнаяСтавкаБаза = База/НормаБаза 2-ой вариант ДневнаяСтавкаБаза = База/ФактБаза
Командировка = ДневнаяСтавкаБаза*ФактДнейВКомандировке
Командировка = ДневнаяСтавкаБаза*ФактДнейВКомандировке
Я еще раз вас призываю, наладьте в голове понятия, которыми оперируете, иначе приступив к сложным задачам вы к конце концов запутаетесь, где у вас что.
Давайте ваш пример приведем в порядок:
1-ый вариант:
ДневнаяСтавка = ЗначениеОклада/НормаВремени;
Оклад = ДневнаяСтавка*ФактОтработанногоВремени;
Командировка = ОкладБаза*ФактВремениВКомандировке;
2-ой вариант:
ДневнаяСтавка = База/ФактБаза - вот тут вы ошибаетесь. Я не встречал в задачах такого значения дневной ставки. Приводите конкретику, будем разбираться.
Отправлено: mik19770727 от Январь 18, 2013, 10:45:49 am
Цитата (sima)
ДневнаяСтавка = База/ФактБаза - вот тут вы ошибаетесь. Я не встречал в задачах такого значения дневной ставки. Приводите конкретику, будем разбираться.
Задача 3.2 "Часовая ставка для расчета командировки определяется как сумма всехначислений за два предыдущих месяца, деленная на количество отработанных часов
в двух предыдущих месяцах. "
Разбираться не нужно, просто такие задачи есть.
Цитата (sima)
Командировка = ОкладБаза*ФактВремениВКомандировке;
Цитата
Цитата (mik19770727)и исходя из этой мизерной ставки расчитаем командировку.
Такое случается, не волнуйтесь. Главное следовать логике задания.
Такое случается, не волнуйтесь. Главное следовать логике задания.
Цитата (sima)
ДневнаяСтавка = ЗначениеОклада/НормаВремени; Оклад = ДневнаяСтавка*ФактОтработанногоВремени;
Спасибо за помощь!
Отправлено: sima от Январь 18, 2013, 10:57:26 am
Цитата (mik19770727)
Часовая ставка для расчета командировки
А! А я думал вы имеете ввиду оклад! Тогда конечно.
Отправлено: SerF от Февраль 04, 2013, 09:42:58 pm
Спасибо за ваши решения.
Выкладываю свой вариант решения. Проверьте, пжлст, кому не лень.
Вложения:
3.01_SerF.dt
Отправлено: fimanich от Март 22, 2013, 10:57:20 pm
Есть некоторые моменты, которые касаются твоего (да и других решений), которые я хотел бы уточнить.
В отчете для чего параметр ДатаКон?
На мой взгляд, там где деление, обязательно должна быть проверка на ноль.
Там где базу для командировки получаем, можно задавать параметр ВидРасчета = Командировка, а не массив Командировка + Оклад.
Еще у меня вопрос насчет функции ЕстьNull: нужно ли ее применять к данным графика, если график - основная таблица запроса? Например, когда основная таблица - База, то для РезультатБаза используем ЕстьNull...
То есть имеет ли смысл писать такой код (для всех полей ЕстьNull):
"ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| ОсновныеНачисленияДанныеГрафика.ВидРасчета,
| ЕСТЬNULL(ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия, 0) КАК ЧасовНорма,
| ЕСТЬNULL(ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия, 0) КАК ЧасовФакт,
| ЕСТЬNULL(СведенияОСотрудникахСрезПоследних.Оклад, 0) КАК Размер,
| ЕСТЬNULL(ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод,0) КАК ЧасовБаза,
| ЕСТЬNULL(ОсновныеНачисленияБазаОсновныеНачисления.РезультатБаза, 0) + ЕСТЬNULL(ОсновныеНачисленияБазаДополнительныеНачисления.РезультатБаза, 0) КАК РезультатБаза
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(
Вообще, виртуальные таблицы регистра расчета в этом плане уникальные, ведь, например, в виртуальных таблицах других регистров ни в каких полях Null быть не может, если таблица основная в запросе...
Прикрепляю свое решение. Критика приветствуется.
Вложения:
fimanich_01_03.dt
Отправлено: fimanich от Март 22, 2013, 11:01:27 pm
Вложения:
fimanich_03_01.dt
Отправлено: fimanich от Март 23, 2013, 03:58:28 pm
Насчет ЕстьNull установил (в отладчике) следующее:
1. Основная таблица - ДанныеГрафика: если график в РС не заполнен, то ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия будет Null => в этой таблице ЕстьNull обязательно
2. Основная таблица - База: если база была когда нибудь для этого сотрудника, то РезультатБаза = 0, но если для сотрудника никогда не было базы, то то такая запись в запрос не попадает => в этой таблице ЕстьNull не нужно.
Подскажите, правильные ли выводы я сделал?
Пока поправил свое решение в соответствии с выводами.
Вложения:
fimanich_03_01_.dt
Отправлено: TuMyP1985 от Август 13, 2013, 08:59:53 pm
Вложения:
KTT_3_1.dt
Отправлено: nskripka от Август 18, 2013, 06:13:20 pm
Вложения:
3_1_nskripka.dt
Отправлено: artfa от Август 26, 2013, 09:39:48 pm
при решении задачи у меня вышла комичная ситуация:
результат база для начисления премии почему-то задваивался, так если если оклад начислен сотруднику 10000, то база выходила 20000, я всю конфигурацию перерыл в поисках ошибки, и когда уже отчаялся, случайно нашел, оказывается я в режиме предприятия добавил в Премию базовый вид расчета Оклад, затем то же самое проделал в режиме конфигуратора, в итоге у меня получилось два раза Оклад как базовый вид расчета для премии, причем в режиме предприятия добавить два одинаковых вида расчет в качестве базового система не даст, это и повлияло на резульат базу, т.е. система считала два раза по двум базовым видам расчета...
при рассмотрении чужих решений я заметил что многие не оптимизируют свои запросы, а также не индексируют измерения регистров
Вложения:
7271554.dt
Отправлено: botokash от Сентябрь 06, 2013, 12:32:22 pm
Вложения:
3826688.dt
Отправлено: Voyager от Октябрь 07, 2013, 10:53:20 pm
Заранее спасибо.Вложения:
Voyager_3.01.dt
Отправлено: artfa от Октябрь 08, 2013, 04:56:19 pm
Цитата (Voyager)
Особенно был бы рад комментариям artfa
1. отчет:
- у вас в параметрах отчета нашел "КонецПериода(&Период.ДатаОкончания, "День")", у Период и так Тип - стандартный период, поэтому у &Период.ДатаОкончания будет дата конец дня, причем включительно, т.е. не надо прибавлять секунду как если бы это было &ДатаНачала и ДобавитьКДате(&ДатаОкончания, "Секунда", 1),
- не критично, но лучше период регистрации сделать ч\з макет чтобы дата отображалсь как январь 2013г., а не 01.01.2013г.
2. Документ НачислениеЗарплаты :
- у период регистрации лучше выставить проерку заполнения (я сам забываю об этом), чтобы уже на стадии обработки заполнения документ выдавал отказ чем на стадии проведении, такой подход меньше нагружает систему,
- у вас одна табличная часть в которую заносятся как основные начисления, так и дополнительные, лучше создать две таб. части, т.к. один из Планов видов расчета имеет период действия, другой нет, и я так думаю что это могут засчитать ошибкой на экзамене,
3. РР:
- для оптимизации работы решения следует отмечать как базовые те измерения регистров расчета, которые наиболее часто будут использованы при получении базы (то же часто забываю это делать), см. Проф. разработка в 1С8.2
в остальной части, с учетом замечаний указанных в п.2, вроде все нормально.
P.S. для вашего же удобства скачайте Каркасную конфигурацию для сдачи спеца по платформе.
переделал свое решение
Вложения:
4918520.dt
Отправлено: Voyager от Октябрь 08, 2013, 06:34:14 pm
После просмотра Вашего решения, появился вопрос: как Вы определяете исходя из формулировок задач в сборнике, в каком случае нужно использовать зависимость по периоду регистрации, в каком - по периоду действия (в этой задаче для ПВР "ДополнительныеНачисления" Вы используете зависимость по периоду регистрации, я по периоду действия и, видимо, это ошибка).
В запросе, где Вы создаете временные таблицы "Базы" и "БазыГотовые", я бы ограничился созданием одной ВТ: получение данных из вложенного запроса (Ваша ВТ "Базы") с последующей группировкой по номеру строки (Ваша ВТ "БазыГотовые").
Понравилась реализация позиционирования на строке в ТЧ документа в случае ошибки (в решениях этой задачи подобного не видел).
Отправлено: artfa от Октябрь 08, 2013, 07:18:07 pm
Цитата (Voyager)
как Вы определяете исходя из формулировок задач в сборнике, в каком случае нужно использовать зависимость по периоду регистрации, в каком - по периоду действия
Цитата (Voyager)
В запросе, где Вы создаете временные таблицы "Базы" и "БазыГотовые", я бы ограничился созданием одной ВТ: получение данных из вложенного запроса (Ваша ВТ "Базы") с последующей группировкой по номеру строки (Ваша ВТ "БазыГотовые").
по хорошему нужно проверить производительность на больших объемах данных, а потом уже сделать вывод - как лучше, я в задачах делаю и так и так как вы предлагаете.
Цитата (Voyager)
Понравилась реализация позиционирования на строке в ТЧ документа в случае ошибки (в решениях этой задачи подобного не видел).
это мое любимое занятие - привязывать СообщениеПользователю к полю формы
Отправлено: Pro100KoT от Январь 21, 2014, 03:38:15 pm
Вложения:
1400208.dt
Отправлено: non1ka от Февраль 02, 2014, 03:05:31 pm
И со своей точки зрения прокомментирую решение задачи artfa,
Ошибки:
1. У командировки в качестве Базы не установлен вид расчета "Премия" в задаче явно указано, что расчет командировки от всех начислений (в т. числе и премии)
2. Расчет результата обязательно должен производится в общем модуле, несмотря на то что в 8.2 модуль объекта компилируется на сервере.
3. Мне кажется некорректным обход выборки и последующий поиск в наборе записей, по номеру строки как индекс. Рекомендую использовать Выборка.НайтиСледующий(По номеру записи), Т.к. как не всегда в наборе записей Индекс будет соответствовать НомерСтроки - 1;
4. Не нужно выносить подразделение в Измерение, это избыточность, ни где в задаче не сказано, что получение базы нужно производить по отдельным подразделениям (максимум реквизит)
Выкладываю свое решение, и сразу замечание, все же "Подразделение" наверное нужно было вынести в реквизиты регистра расчета, потому что для формирования отчетов нельзя использовать данные из справочников, но уже не буду исправлять. Но уж точно не в Измерение, не где в задачи не сказано получение базы по Подразделению, это избыточность регистра и ошибка.
Добавлено (02.02.2014, 14:51)
---------------------------------------------
Pro100KoT,
1. У Вас при расчете премии есть код
Цитата
Движение.БазовыйПериодНачало = НачалоМесяца(ПериодРегистрации);
Движение.БазовыйПериодКонец = КонецМесяца(ПериодРегистрации);
Движение.БазовыйПериодКонец = КонецМесяца(ПериодРегистрации);
Ни где в задаче не сказано, что премия начисляется за месяц, она может быть рас читана за любой период, просто оклад нужно брать за этот период начисления соответствующий начислению премии.
2. Командировка "Всегда рассчитывается по пятидневке"
Понравился подход к расчету, комментировать не буду, просто просмотрел десяток видео по решению задач, ни где не видел такого подхода к расчету.
Добавлено (02.02.2014, 15:02)
---------------------------------------------
Еще 1 комментарий по подразделениям.
Мне кажется, что самым правильным, было бы решение вынести подразделение в регистр "Сведения о сотруднике", и при расчете рабочего набора записей автоматически подставлять его в реквизит "Подразделение" регистров расчета.
Еще одно замечание Pro100KoT, Вы не обеспечиваете корректность расчета оклада, вы не помещаете значение оклада (полученного из регистра сведений) в реквизит регистра расчета. Это обязательно для курсов валют, коэффициентов единиц измерения и т.п..
И желательно "Размер" оклада все же указывать на момент записи рабочих наборов. а не в момент получения базы и расчета оклада.
Добавлено (02.02.2014, 15:05)
---------------------------------------------
Кстати на правах рекламы Павла Чистова
Если у Вас есть сомнения в решении задач, приобретите курс http://курсы-по-1с.рф/dev-attestation/startpage/
Очень полезный курс....
Вложения:
4322718.dt
Отправлено: IT_PROGRAMMIST от Февраль 03, 2014, 12:53:47 pm
Вложения:
3_1IT.dt
Отправлено: Leo705 от Март 27, 2014, 09:43:08 am
Пусть Гуру глянут
Вложения:
Leo705_3.1.dt
Отправлено: Alyx Ruby от Август 18, 2014, 06:27:14 pm
То есть начала разбирать СПР. Получилось вроде, возни было много, да еще платформа 8.3.4 глючная какая-то. Пожалуйста, посмотрите мое решение, приму любую конструктивную критику. Хотелось бы решать метологически правильно, признаю заранее, что возможно, имеются недочеты и недоработки по неопытности. 
Вложения:
AlyxRuby3_1.dt
Отправлено: Leo705 от Август 28, 2014, 12:28:11 pm
Цитата AlyxRuby (
)
)Пожалуйста, посмотрите мое решение, приму любую конструктивную критику
1. Отсутствие подсистем;
2. Движение.БазовыйПериодКонец = ДобавитьМесяц(КонецМесяца(Выборка.ДатаОкончания), -1)
Как я писал (и многие другие) уже где-то на этом форуме, при подобной конструкции и значении например: Выборка.ДатаОкончания = '25.02.14', значение Движение.БазовыйПериодКонец будет = '28.01.14', что не есть хорошо
3. Лично я в РР "Подразделение" сделал бы как реквизит, т.к. в условии задачи не сказано, что сотрудник может работать по совместительству, а следовательно базу по подразделению получать необходимости нет;
4. В базу командировки не включена премия;
5. Перерасчеты не нужны, следовательно флаги ведущих видов расчетов тоже;
6. В случае расчета командировки, лично я, сделал бы график всегда пятидневка, а не из ТЧ;
Ну а в остальном, каждый принимает решение сам
Отправлено: Alyx Ruby от Август 31, 2014, 01:09:56 pm
А то я уж подумала что никто и не посмотрит мое решение... 1. Подсистемы, каюсь, позабыла про них, в следующий раз учту.
2. пункт наверно стоить сделать так: Движения.БазовыйПериодКонец = КонецМесяца(ДобавитьМесяц(Выборка.ДатаОкончания), -1) По логике вроде так будет правильнее. Если нет то подскажите, пожалуйста, правильный вариант.
3. Это правда лишнее, я просто пробовала более детальный вариант решения. Хотя на экзамене, конечно, не стоит увлекаться
4. Упс и действительно забыла, хотя в запросе учла.
5. Это тоже тренировалась, а как на экзамене, точно не стоит указывать?
Позже выложу переделанный вариант. Сейчас немного некогда, но попозже обязательно вернусь к этим задачкам...
Отправлено: Leo705 от Сентябрь 01, 2014, 11:00:39 am
Цитата AlyxRuby ()
)2. пункт наверно стоить сделать так:
Да
Цитата AlyxRuby ()
)5. Это тоже тренировалась, а как на экзамене, точно не стоит указывать?
Ну на сколько помню я, то они используются при перерасчетах, я бы не указывал.
Отправлено: Demy от Сентябрь 03, 2014, 11:26:20 am
Вложения:
Demy_3.01.dt
Отправлено: EfKonstanin от Сентябрь 14, 2014, 12:56:49 pm
Цитата: Demy;35978
Моя первая задача по расчетам. Буду благодарен за пинок в нужном направлении!
Прикрепления: Demy_3.01.dt(199Kb)
Словосочетание : "Премия может быть начислена в том же расчетном периоде", говорит о том что зависимость по базе для Доп. начислений должна быть по Периоду регистрации. Измерение "Сотрудник" должно быть проиндексировано т.к. ты связываешь, 2 регистра по этому измерению, если бы у тебя использовалось 2 измерения в РР и нужно было бы осуществлять по ним связь, то нужно было бы поставить признак "Базовое". Поправьте , если что не так.
Отправлено: Demy от Сентябрь 18, 2014, 09:10:23 am
Цитата EfKonstanin ()
)Словосочетание : "Премия может быть начислена в том же расчетном периоде", говорит о том что зависимость по базе для Доп. начислений должна быть по Периоду регистрации.
Цитата EfKonstanin ()
)Измерение "Сотрудник" должно быть проиндексировано т.к. ты связываешь, 2 регистра по этому измерению
Спасибо!
Отправлено: Wowa_T от Октябрь 17, 2014, 10:53:54 am
Как прикрепить внешний файл в сообщение?
Что то не нахожу
Отправлено: ocean5 от Декабрь 10, 2014, 12:40:34 pm
Если в задании есть фраза:"начисление зарплаты ведётся методом отклонений" тогда табель точно не нужен.
УВАЖАЕМЫЕ, на официальном открытом форуме 1с http://devtrainingforum.v8.1c.ru/forum написаны слова преподавателей «Учет отработанного времени реализуется методом "отклонений", при котором учет отработанного времени ведется по графикам работы с регистрацией отклонений от нормальной продолжительности рабочего времени такими расчетными документами, как больничные листы, отпуска, простои и т.д.» Т.е. табеля делаем по любому!
Отправлено: ВиталийЧебан от Декабрь 10, 2014, 04:19:20 pm
Здесь у кого-то был спор, что означает фраза задачи Начисление зарплаты сотрудникам предприятия осуществляется ежемесячно с использованием метода отклонений. Тут народ писал, что
Если в задании есть фраза:"начисление зарплаты ведётся методом отклонений" тогда табель точно не нужен.
УВАЖАЕМЫЕ, на официальном открытом форуме 1с http://devtrainingforum.v8.1c.ru/forum написаны слова преподавателей «Учет отработанного времени реализуется методом "отклонений", при котором учет отработанного времени ведется по графикам работы с регистрацией отклонений от нормальной продолжительности рабочего времени такими расчетными документами, как больничные листы, отпуска, простои и т.д.» Т.е. табеля делаем по любому!
Табель нужен исключительно в случае явного требования в задаче.
Отправлено: Wowa_T от Февраль 21, 2015, 08:45:16 am
Покритикуйте пож.
Отправлено: Jones от Апрель 02, 2015, 11:25:02 am
Покритикуйте пож.
1) Есть мнение, что в ПВР ДопНачисления надо устанавливать зависимость от базы «По периоду РЕГИСТРАЦИИ», т.к. в задании есть строка «…премия процентом от начисленного в том же расчетном периоде оклада…»
2) В документе рекомендуется делать отдельную ТЧ на каждый регистр
3) не нужны строки:
Движения.ОсновныеНачисления.Записывать = Истина;
Движения.ДополнительныеНачисления.Записывать = Истина;
4) Для оклада указывать базовый период не нужно
5) Для Командировки нет проверки, что ее нельзя вводить задним числом
6) Получение двух предыдущих месяцев для базового периода Командировки выглядит как-то странно, хотя работать будет:
Движение.БазовыйПериодНачало = НачалоМесяца(НачалоМесяца(НачалоМесяца(Дата) - 1)-1);
7) В запросе РасчитатьОсновныеНачисления() слева находится таблица База
Павел Чистов в вебинарах по СПР утверждает, что, при отсутствии данных для расчета, в таблице база не будет записей, поэтому таблицу База слева в запросе располагать нельзя.
Слева должна быть ВТ ДанныеГрафика, либо физическая таблица регистра.
8) При расчете Премии сделано так:
Запись.Результат = Запись.Размер * Выборка.РезультатБаза/100 ;
Так будет корректнее
Запись.Результат = Запись.Размер /100 * Выборка.РезультатБаза;
9) При расчете ДопНачислений перерасчет периода действия отменять не обязательно
Истина можно убрать:
Движения.ДополнительныеНачисления.Записать(, Истина);
10) Рассчет Основных и ДопНачислений желательно производить именно в общем модуле, несмотря на то, что модуль документа компилируется на сервере.
Отправлено: Jones от Апрель 03, 2015, 03:27:20 pm
Кто готовится к Спецу по v8, и Кто уже сдал, прошу проверить мой вариант решения и указать на недостатки, если они есть :)
Отправлено: naumenko_alex от Апрель 05, 2015, 05:22:48 pm
Народ!
Кто готовится к Спецу по v8, и Кто уже сдал, прошу проверить мой вариант решения и указать на недостатки, если они есть :)
1.Считаю реквизит "РасчетныйПериод" в документе Начисление ЗП избыточным. Для доп.начислений нужно использовать период регистрации.
2.База в ПВХ "основные начисления" зависит по периоду действия, а не регистрации так как в условии задачи сказано что командировка начисляется как сумма начислений за 2 пред. месяца, а не начисленных в 2 пред. месяцах.
3. Считаю не совсем правильной ситуацию когда в документе и в регистре разные данные. Например Период регистрации в док. 16 а в регистре 01.
4. Ошибка при расчете премии при отсутствии данных по базе. т.е. по окладу.
5. Ошибка при проверку ввода командировки задним числом. Нужно сравнивать период регистрации, а не текущую дату.
6. В отчете итоговые данные по горизонтали скорее всего лишние так как в макете их нет.
ПРИКЛАДЫВАЮ СВОЙ ВАРИАНТ ;)
Отправлено: Jones от Апрель 06, 2015, 05:56:24 pm
ПРИКЛАДЫВАЮ СВОЙ ВАРИАНТ ;)
1.СОГСЛАСЕН, исправил. :)
2. НЕ СОГЛАСЕН. Вы уверены, что правильно понимаете смысл вида зависимости от базы?
3. НЕ ПОНЯЛ. Можно поточнее, это где такое? О чем речь?
4. СОГЛАСЕН, глупая ошибка. Добавил проверку перед делением :)
5. Возможно, Вы правы.
6. СОГЛАСЕН, итоги по горизонталиотключил. Как думаете, если этого не сделать, это ошибкой не станет?
naumenko_alex, в Вашем варианте серьезных ошибок я не нашел, а отчет вообще шикарный. Принимаю на вооружение.
Отправлено: naumenko_alex от Апрель 06, 2015, 08:35:51 pm
Спасибо за отзыв :)
ПРИКЛАДЫВАЮ СВОЙ ВАРИАНТ ;)
1.СОГСЛАСЕН, исправил. :)
2. НЕ СОГЛАСЕН. Вы уверены, что правильно понимаете смысл вида зависимости от базы?
Смотри если оставить в ПВР Осн.Нач. зависимость от периода регистрации то получиться так например что при расчете командировки допустим за январь будут включены в базу начисления с периодом регистрации ноябрь и декабрь, а период регистрации может не совпадать с периодом действия. Например мы начислим оклад за октябрь(период действия) в ноябре(период регистрации) и тогда оклад начисленный за октябрь попадет в расчетную базу командировки за январь, а это ошибка.
3. НЕ ПОНЯЛ. Можно поточнее, это где такое? О чем речь?
Я имею ввиду что у тебя в документе в реквизитах записано в базу данных значения например для периода регистрации 16 января, для графика работы в командировке шестидневка и тд. ,а в регистре записано что период регистрации 1 января и график работы пятидневка соответственно это не правильно данные в регистраторе и регистре должны быть одинаковыми.
4. СОГЛАСЕН, глупая ошибка. Добавил проверку перед делением :)
5. Возможно, Вы правы.
6. СОГЛАСЕН, итоги по горизонталиотключил. Как думаете, если этого не сделать, это ошибкой не станет?
Затрудняюсь с ответом.
naumenko_alex, в Вашем варианте серьезных ошибок я не нашел, а отчет вообще шикарный. Принимаю на вооружение.
Отправлено: rusmosav от Апрель 14, 2015, 04:45:32 am
Отправлено: tsmgeorg от Август 04, 2015, 07:38:17 pm
Отправлено: Zeskord от Сентябрь 29, 2015, 12:38:04 pm
ПРИКЛАДЫВАЮ СВОЙ ВАРИАНТ ;)А почему подразделение - измерение регистра? Ведь в условии задачи нет таких требований.
Отправлено: ID443 от Ноябрь 25, 2015, 10:41:17 am
ВЫБРАТЬ
| ОсновныеНачисленияДанныеГрафика.НомерСтроки,
| ОсновныеНачисленияДанныеГрафика.ВидРасчета,
| ОсновныеНачисленияДанныеГрафика.ЗначениеПериодДействия КАК ПериодДействия,
| ОсновныеНачисленияДанныеГрафика.ЗначениеФактическийПериодДействия КАК Факт,
| ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод КАК База,
| ЕстьNULL(СведенияОСотрудникахСрезПоследних.Оклад, 0) Оклад
|ИЗ
| РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(Регистратор = &Регистратор) КАК ОсновныеНачисленияДанныеГрафика
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СведенияОСотрудниках.СрезПоследних(&Период, ) КАК СведенияОСотрудникахСрезПоследних
| ПО ОсновныеНачисленияДанныеГрафика.Сотрудник = СведенияОСотрудникахСрезПоследних.Сотрудник
| И ОсновныеНачисленияДанныеГрафика.Подразделение = СведенияОСотрудникахСрезПоследних.Подразделение
|ГДЕ
| ОсновныеНачисленияДанныеГрафика.Регистратор = &Регистратор
Отправлено: pila86 от Декабрь 20, 2015, 02:49:48 pm
Отправлено: ALF1360 от Декабрь 24, 2015, 09:53:43 am
Отправлено: Odines от Январь 26, 2016, 10:34:23 pm
Отправлено: Марк от Февраль 19, 2016, 11:18:10 am
Отправлено: Марк от Февраль 29, 2016, 06:46:02 am
Отправлено: CSiER от Март 31, 2016, 10:09:47 am
Буду признателен за критику. Первое решение по расчетным задачам.Можете прикрепить dt ?
Отправлено: ирко от Апрель 05, 2016, 01:30:21 am
Может кто-нибудь внятно объяснить, почему так??? Вообще не догоняю!Покритикуйте пож.
1) Есть мнение, что в ПВР ДопНачисления надо устанавливать зависимость от базы «По периоду РЕГИСТРАЦИИ», т.к. в задании есть строка «…премия процентом от начисленного в том же расчетном периоде оклада…»
Отправлено: alfalume от Июнь 11, 2016, 11:58:00 am
Отправлено: pns от Июль 11, 2016, 06:50:31 pm
Отправлено: alex_1980 от Сентябрь 08, 2016, 02:01:27 pm
Отправлено: GH0STexe от Сентябрь 13, 2016, 08:57:38 am
Не много модернизировал свое решение :) Интересно а на экзамене можно использовать оператор Попытка?Насколько мне известно в актуальных задачах нет ситуаций где пригодится эта конструкция. Так что лучше её не использовать
Отправлено: erdem.badluev от Октябрь 07, 2016, 11:42:29 am
Хоть кто-нибудь, посмотрите!
Есть ли ошибки?
Отправлено: Сергей1972 от Март 22, 2017, 10:10:58 pm
А как быть с тем, что
"Все сотрудники работают по
пятидневному графику работы, однако в решении необходимо предусмотреть
возможность работы по нескольким различным графикам."
Нет у Вас этого. Так ведь?
Отправлено: Maxipunchik от Июль 07, 2018, 10:38:46 am
Отправлено: ComradeKite от Июль 08, 2018, 12:43:11 am
Почему у многих в измерениях подразделение? В двухтомнике однозначно написано, что так делать нельзя:А двухтомик то причем здесь?
Измереие или реквизит зависит, совместительство допускается или нет. Если совместительство допускается, значит и записи надо в регистре расчетов делить по подразднлению, а это достигается добавлением измерения подразделение. Если совмещать не надо и в отчете нет поля подразделение, да и вообще подразднление не упоминается, то его можно никуда не добавлять. Если в разрезе подразделения считать не надо, а в отчете есть колонка подразделение, то надо добавить реквизит.
В этой задаче я бы сделал реквизитом, так как про совместительство ничего не сказано.
Ну можно и измерением, если хотите и будете сдавать очно, это вызовет дополнительный вопрос у преподавателя. Если сможете объяснить, то проблем нет, а вот если не сможете, то препод сразу увидит что вы не в теме.
Отправлено: Scalli от Август 23, 2018, 10:33:24 am
Отправлено: Stanislaw от Май 09, 2020, 06:19:10 pm
Отправлено: nikola17 от Февраль 01, 2021, 11:18:10 pm
В этой задаче я бы сделал реквизитом, так как про совместительство ничего не сказано.Во всех (50) задачах по СПР нигде не сказано про совместительство.
Ну можно и измерением, если хотите и будете сдавать очно, это вызовет дополнительный вопрос у преподавателя. Если сможете объяснить, то проблем нет, а вот если не сможете, то препод сразу увидит что вы не в теме.
Отправлено: ProhorP от Февраль 19, 2021, 07:21:37 am
Прежде чем приступать к решению посмотрите бесплатное видео от Чистова
Цитировать
https://1c.chistov.pro/2009/12/1-82.html
Отправлено: Sdnv от Март 13, 2021, 09:01:40 pm
В задаче 3.1. требуется одновременно
1. осуществлять начисление методом отклонений
2. сотрудники получают оплату пропорционально отработанному времени
3. Ввод всех начислений происходит одним документом "Начисление зарплаты"
Правильно я понимаю, что нужно предусмотреть имя расчета "не работал" с нулевым окладом, чтобы он вытеснял нормальный оклад (отклонение от нормы)?