Форум Чистова. Подготовка к экзаменам 1С
Аттестация "1С:Специалист" => Аттестация "1С:Специалист по платформе 1С:Предприятие 8.3 и 8.2" => Тема начата: Михаил Проходцев от Июнь 29, 2016, 09:02:03 pm
-
Коллеги, по отзывам тех, кто уже испытывал судьбу на экзамене, можно составить встретившиеся на экзамены задачи, подзадачи, не встречающиеся в Актуальных билетах. Предлагаю на этой ветке обсуждать их, выкладывать свои решения.
Итак, BobbyOs подготовил список таких задач на текущий момент:
1) Отображение результатов расчета в форме начисления зарплаты с целью редактирования
2) График с дискретностью 15 мин для учета опозданий и начисления штрафов.
3) Прямая запись в таблицы перерасчета при проведении по регистрам накопления или бухгалтерии
4) Реализация процедуры перерасчета.
5) Премия с периодом действия и ее вытеснение выплатами фиксированных сумм
6) Вечерние часы по повышенной на 50% ставке
7) Документ "Выплата зарплаты" с автозаполнением по результатам начисления
8 ) Учет испорченных товаров в задаче о скоропортящихся товаров
Итак, начнем:
1. По отображению результатов расчета в форме вопросов особо нет - добавляем команду, вызываем процедуру модуля объекта Рассчитать, в которую переносим всё, что в обработке проведения. В документ добавляем измерения и реквизиты, присутствующие в регистре, заполняем их. При проведении просто данные из документы последовательно записываем в регистры расчета. Реализация этой задачи в первом билете во вложении.
2. С условием "за каждые целые 15 минут опоздания начисляется штраф" всё сложнее. Подобное обсуждалось при решении задачи 3.24 (http://forum.chistov.pro/index.php?topic=1182.0) и в ветке "Результаты сдачи экзаменов", но к окончательному решению нигде не пришли, кто-то предлагает вводить количество 15 минуток опозданий, кто-то рассчитывать минуты опоздания и делить на 15, кто-то в графиках фиксировать не часы, а 15 минутки. Как Вы считаете (или успешно реализовали на экзамене) какой алгоритм здесь правильный?
3) Программная запись в таблицы перерасчета, здесь для меня совсем всё туманно. Не нашел какого-то конкретного обсуждения этого вопроса.
На примере 6 билета, где попадалось это нововведение. Есть вид расчета Надбавка, которая зависит от суммы оплаты пассажиров, а еще есть вид расчета Отпуск, у которого базовым выступает вид расчета Надбавка. Так вот, получается при изменении в документе, фиксирующем суммы оплаты, для правильного начисления по расчетам необходимо перепровести связанный документ Начисление с видом расчета Надбавка, а затем связанные документы с видом расчета Отпуск. Непонятно у нас должна информация в перерасчеты попасть как по документам, связанным с видом расчета Надбавка, так и с видом расчета Отпуск? И как должен осуществляться этот поиск - при проведении документа Сумма оплата с отбором данных этого документа по таблице регистра расчета по периоду и паре Сотрудник, Автомобиль или я чего то не понимаю? Нужна Ваша помощь, специалисты.
4)Реализация процедуры перерасчета. - я так понимаю, получаем данные из таблицы перерасчета и осуществляем расчет наборов записей соответствующих документов.
5) Условие " За произвольные период отработанного времени (должен указываться в документе и может быть меньше периода ведения расчетов, например несколько дней) сотрудникам выплачивается премия процентом от оклада, начисленного за те же дни, за которые была начислена премия. Плюс за любой день может быть вместо премии выплачена любая сумма". Решение - Премия и Произвольная сумма в начисления с ПД, Произвольная сумма вытесняет Оклад. Для вида расчета Премия флажок "Период Действия является базовым"
6) "Три дня в неделю (пон.,среда, пятница) по два часа работы приходится на вечерние часы. За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу" - заводим доп ресурс вечерние часы в графиках. Не совсем понятно, должен ли это быть отдельный вид расчета или сумма должна добавляться при расчете оклада. Наверно, всё-таки отдельный вид расчета, может будет больше понятно в контексте конкретной задачи
7) Документ "Выплата зарплаты" с автозаполнением по результатам начисления. Здесь вроде всё понятно - регистр остатков, в который Начисление делает приход, а документ Выплата - расход.
8 ) Учет испорченных товаров в задаче о скоропортящихся товаров. Текст задания и реализованное на экзамене решение http://forum.chistov.pro/index.php?topic=993.msg44431#msg44431
-
2. С условием "за каждые целые 15 минут опоздания начисляется штраф" всё сложнее. Подобное обсуждалось при решении задачи 3.24 (http://forum.chistov.pro/index.php?topic=1182.0) и в ветке "Результаты сдачи экзаменов", но к окончательному решению нигде не пришли, кто-то предлагает вводить количество 15 минуток опозданий, кто-то рассчитывать минуты опоздания и делить на 15, кто-то в графиках фиксировать не часы, а 15 минутки. Как Вы считаете (или успешно реализовали на экзамене) какой алгоритм здесь правильный?
Я бы делал с фиксацией в графиках 15 минуток. Мне кажется здесь как раз проверяется, как вы умеете работать со временем и графиками, даже в таком извращенном варианте.
Количество 15-минуток сделать имеет к расчету более опосредованное отношение
6) "Три дня в неделю (пон.,среда, пятница) по два часа работы приходится на вечерние часы. За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу" - заводим доп ресурс вечерние часы в графиках. Не совсем понятно, должен ли это быть отдельный вид расчета или сумма должна добавляться при расчете оклада. Наверно, всё-таки отдельный вид расчета, может будет больше понятно в контексте конкретной задачи
Однозначно отдельный ВР на каждый алгоритм.
7) Документ "Выплата зарплаты" с автозаполнением по результатам начисления. Здесь вроде всё понятно - регистр остатков, в который Начисление делает приход, а документ Выплата - расход.
Там не все так очевидно и зависит от точной формы отчета, которую никто не видел. Но могу только сказать, что делать документ по выплате в разрезе видов начислений - это моветон
На остальные вопросы либо уже писал, либо слишком много писать...
-
2) График с дискретностью 15 мин для учета опозданий и начисления штрафов.
В задаче сказано, что за каждые 15 минут, значит вид расчета периодический. И либо он работает параллельно с окладом, что логически неверно, либо вытесняет оклад. А значит надо делать регистр сведений с минутной периодикой, и заполнять график через каждые 15 минут. Кода там добавляется с грамм. Да и в ТЧ поменять ДатаНачала и ДатаОкончания, на "Дата с временем".
С Гакусей абсолютно согласен.
3) Программная запись в таблицы перерасчета, здесь для меня совсем всё туманно. Не нашел какого-то конкретного обсуждения этого вопроса.
На примере 6 билета, где попадалось это нововведение. Есть вид расчета Надбавка, которая зависит от суммы оплаты пассажиров, а еще есть вид расчета Отпуск, у которого базовым выступает вид расчета Надбавка. Так вот, получается при изменении в документе, фиксирующем суммы оплаты, для правильного начисления по расчетам необходимо перепровести связанный документ Начисление с видом расчета Надбавка, а затем связанные документы с видом расчета Отпуск. Непонятно у нас должна информация в перерасчеты попасть как по документам, связанным с видом расчета Надбавка, так и с видом расчета Отпуск? И как должен осуществляться этот поиск - при проведении документа Сумма оплата с отбором данных этого документа по таблице регистра расчета по периоду и паре Сотрудник, Автомобиль или я чего то не понимаю? Нужна Ваша помощь, специалисты.
Отпуск берётся по всем начислениям, в том числе и от надбавки. Значит надбавка у него ведущая. Достаточно изменить надбавку и РР автоматом добавит запись по отпуску в перерасчёты. Отпуск трогать не надо.
А вот у надбавки зависимость от РБ, где разработчиками не создана процедура зависимости, а значит надо её создавать самому. При проводке документа поступление денег(в РБ), запросом получаем все записи из РР где период регистрации (т.к. все записи в документах за один расчетный период) больше или равно начало следующего месяца от даты документа приход денег и вид расчета равен виду надбавка. Обрабатываем запрос и добавляем в перерасчёты. Ещё раз повторюсь - в перерасчётах будет создана только вид надбавка. Когда начнутся проводить документы по надбавке, платформа автоматом начнёт добавлять ведомые по отпускам.
-
6) "Три дня в неделю (пон.,среда, пятница) по два часа работы приходится на вечерние часы. За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу" - заводим доп ресурс вечерние часы в графиках. Не совсем понятно, должен ли это быть отдельный вид расчета или сумма должна добавляться при расчете оклада. Наверно, всё-таки отдельный вид расчета, может будет больше понятно в контексте конкретной задачи
Однозначно отдельный ВР на каждый алгоритм.
Значит в этой задаче просто в регистре графиков ресурс количества вечерних часов, новый вид расчета с ПД, из виртуальной таблицы данных графика берем количество часов и рассчитываем в соответствии с условием задания.
7) Документ "Выплата зарплаты" с автозаполнением по результатам начисления. Здесь вроде всё понятно - регистр остатков, в который Начисление делает приход, а документ Выплата - расход.
Там не все так очевидно и зависит от точной формы отчета, которую никто не видел. Но могу только сказать, что делать документ по выплате в разрезе видов начислений - это моветон
Один из участников форумы выкладывал измененный билет №2, который попался ему на экзамене, там были следующие поля отчета - Сотрудник, Вид расчета, Нач. сальдо, Начислено, Выплачено, Кон. сальдо. Мне кажется, этим отчетом и определяется структура регистра - измерения Сотрудник, ВидРасчета, Ресурс Сумма. Соответственно и отчет будет отлично собираться из виртуальной таблицы остатков и оборотов.
-
2) График с дискретностью 15 мин для учета опозданий и начисления штрафов.
В задаче сказано, что за каждые 15 минут, значит вид расчета периодический. И либо он работает параллельно с окладом, что логически неверно, либо вытесняет оклад. А значит надо делать регистр сведений с минутной периодикой, и заполнять график через каждые 15 минут. Кода там добавляется с грамм. Да и в ТЧ поменять ДатаНачала и ДатаОкончания, на "Дата с временем".
С Гакусей абсолютно согласен.
Спасибо за разьяснения, значит в регистре графиков будет не 8 часов, а 32 пятнадциминутки, и вытеснение будет именно в этой единице... Попробую реализовать, может действительно не так это и страшно, как кажется на первый взгляд.
3) Программная запись в таблицы перерасчета, здесь для меня совсем всё туманно. Не нашел какого-то конкретного обсуждения этого вопроса.
На примере 6 билета, где попадалось это нововведение. Есть вид расчета Надбавка, которая зависит от суммы оплаты пассажиров, а еще есть вид расчета Отпуск, у которого базовым выступает вид расчета Надбавка. Так вот, получается при изменении в документе, фиксирующем суммы оплаты, для правильного начисления по расчетам необходимо перепровести связанный документ Начисление с видом расчета Надбавка, а затем связанные документы с видом расчета Отпуск. Непонятно у нас должна информация в перерасчеты попасть как по документам, связанным с видом расчета Надбавка, так и с видом расчета Отпуск? И как должен осуществляться этот поиск - при проведении документа Сумма оплата с отбором данных этого документа по таблице регистра расчета по периоду и паре Сотрудник, Автомобиль или я чего то не понимаю? Нужна Ваша помощь, специалисты.
Отпуск берётся по всем начислениям, в том числе и от надбавки. Значит надбавка у него ведущая. Достаточно изменить надбавку и РР автоматом добавит запись по отпуску в перерасчёты. Отпуск трогать не надо.
А вот у надбавки зависимость от РБ, где разработчиками не создана процедура зависимости, а значит надо её создавать самому. При проводке документа поступление денег(в РБ), запросом получаем все записи из РР где период регистрации (т.к. все записи в документах за один расчетный период) больше или равно начало следующего месяца от даты документа приход денег и вид расчета равен виду надбавка. Обрабатываем запрос и добавляем в перерасчёты. Ещё раз повторюсь - в перерасчётах будет создана только вид надбавка. Когда начнутся проводить документы по надбавке, платформа автоматом начнёт добавлять ведомые по отпускам.
Здесь тоже стало понятнее. Действительно зачем еще программно анализировать вид расчета Отпуск, когда механизмами системы итак при проведении начислений по надбавке, данные по отпускам отразятся в перерасчетах. Не совсем только понял, почему берем записи, где период регистрации больше или равен началу следующего месяца, получается при изменении в январе, мы добавим в перерасчет и февральские, и мартовский, и апрельские записи. У нас (говоря о 6 билете) собираются же данные за прошлый месяц, значит достаточно будет взять только следующий месяц или я не прав? И, наверно, нужно будет еще отбор сделать по сотруднику указанному в документе ОплатаПассажиров с сотрудником регистра, чтобы лишние записи не хапануть.
-
Спасибо за разьяснения, значит в регистре графиков будет не 8 часов, а 32 пятнадциминутки, и вытеснение будет именно в этой единице... Попробую реализовать, может действительно не так это и страшно, как кажется на первый взгляд.
Не забудь при заполнении, что в рабочих сутках всего 8 часов. Я на каждую запись с 8:00 по 16:00 писал в ресурс 0.4. (обед в расчёт не брал)
Здесь тоже стало понятнее. Действительно зачем еще программно анализировать вид расчета Отпуск, когда механизмами системы итак при проведении начислений по надбавке, данные по отпускам отразятся в перерасчетах. Не совсем только понял, почему берем записи, где период регистрации больше или равен началу следующего месяца, получается при изменении в январе, мы добавим в перерасчет и февральские, и мартовский, и апрельские записи. У нас (говоря о 6 билете) собираются же данные за прошлый месяц, значит достаточно будет взять только следующий месяц или я не прав? И, наверно, нужно будет еще отбор сделать по сотруднику указанному в документе ОплатаПассажиров с сотрудником регистра, чтобы лишние записи не хапануть.
Ну, там вроде база по окладу за 3 предыдущих месяца, а значит следовательно взять за 3 следующих месяца. И отбор по сотруднику, согласен.
-
Один из участников форумы выкладывал измененный билет №2, который попался ему на экзамене, там были следующие поля отчета - Сотрудник, Вид расчета, Нач. сальдо, Начислено, Выплачено, Кон. сальдо. Мне кажется, этим отчетом и определяется структура регистра - измерения Сотрудник, ВидРасчета, Ресурс Сумма. Соответственно и отчет будет отлично собираться из виртуальной таблицы остатков и оборотов.
В том билете только названия колонок и итого. Как расположены сами данные в нем не видно, они пустые
-
А вот какой вопрос возник: зачем делать график по 15 минут, как некоторые указывали еще в обсуждении задачи 3.24, ведь вытеснения по условию задачи нет?
А если считать время опозданий, то предлагаю проверить такой вариант:
Есть записи по 15 минут в регистре сведений, есть опоздание у работника, например, с 8:00 по 8:17.
Проводим документ и в запросе из видим, что по данным графика опоздание уже 30 минут.
Т.е. для корректного подсчета времени опоздания нужно делать регистр поминутно, но здесь другой вопрос, а нужен ли такой монстр при отсутствии вытеснений, да и ограничение учебной версии по количеству записей в регистре никто не отменял.
-
А вот какой вопрос возник: зачем делать график по 15 минут, как некоторые указывали еще в обсуждении задачи 3.24, ведь вытеснения по условию задачи нет?
А если считать время опозданий, то предлагаю проверить такой вариант:
Есть записи по 15 минут в регистре сведений, есть опоздание у работника, например, с 8:00 по 8:17.
Проводим документ и в запросе из видим, что по данным графика опоздание уже 30 минут.
Т.е. для корректного подсчета времени опоздания нужно делать регистр поминутно, но здесь другой вопрос, а нужен ли такой монстр при отсутствии вытеснений, да и ограничение учебной версии по количеству записей в регистре никто не отменял.
Т.е. Если сотруднику по окладу начисляется в среднем за каждые 15 минут 200 рублей (утрированно), а снимается 100, то на работу можно ходить только за деньгами. Я бы хотел такую работу. А в регистре начинать делать первую запись не с 0:00:00 а с 0:14:59 и прибавлять по 15 минут. Вытеснение работает как положено. Если сотрудник опоздал на 29 минут, то вытесняется только 1 запись регистра.
А вообще никто не запрещает делать так как хочешь. Главное доказать проверяющему почему так правильней.
-
Спасибо за разьяснения, значит в регистре графиков будет не 8 часов, а 32 пятнадциминутки, и вытеснение будет именно в этой единице... Попробую реализовать, может действительно не так это и страшно, как кажется на первый взгляд.
Не забудь при заполнении, что в рабочих сутках всего 8 часов. Я на каждую запись с 8:00 по 16:00 писал в ресурс 0.4. (обед в расчёт не брал)
Почему в ресурсе 0.4? Я так понял, если реализуем вытеснение оклада опозданиями, то в графике два ресурса - один фиксирует единицы каждые 15 минут (для подсчета количества пятнадциминутных опозданий), а во втором - количество часов в интервале, т.е. 0.25. для подсчета отработанных часов оклада.
-
Значит в этой задаче просто в регистре графиков ресурс количества вечерних часов, новый вид расчета с ПД, из виртуальной таблицы данных графика берем количество часов и рассчитываем в соответствии с условием задания.
А если сделать Оклад - базовым для вечерних часов и отдельный график дни них? Доработка обработки заполнения графика проще, только часы добавить. При расчете количество вечерних часов из данных графика получаем. А часовую ставку из:
1) По базе - Сумма оклада / Отработано часов
2) Добавляем отдельный реквизит "часовая ставка" - куда записываем при расчете оклада
Из "параметра" получаем процент надбавки за вечерние часа.
Мне кажется это более гибко, если например добавятся надбавки за ночные часы с другим расчетом. Не придётся добавлять ещё ресурс в график.
-
Значит в этой задаче просто в регистре графиков ресурс количества вечерних часов, новый вид расчета с ПД, из виртуальной таблицы данных графика берем количество часов и рассчитываем в соответствии с условием задания.
А если сделать Оклад - базовым для вечерних часов и отдельный график дни них?
Здесь не все так просто. А какой будет этот график - для вечерних часов? Если у сотрудник основной график пятидневка, то доплата будет за работу в понедельник, среду и в пятницу. А если его график - работа только в выходные? Тогда ему совсем не светят вечерние часы. Тут универальный график не сделаешь для вечерних часов.
Перечитал несколько (десятков, а может и сотен) раз условие задачи "Три дня в неделю (пон.,среда, пятница) по два часа работы приходится на вечерние часы. За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу" Два часа работы ПРИХОДЯТСЯ- то есть это два часа из графика по окладу, которые должны быть оплачены сверх ставки. Идеально простое решение - новый ресурс в графике количество вечерних часов и ПРИ РАСЧЕТЕ ОКЛАДА рассчитывать результат как КоличествоЧасовФакт * ТарифнаяСтавка + КоличествоВечернихЧасовФакт*0.5*ТарифнаяСтавка. В чем плюс решения - здесь уже будет рассчитана ТарифнаяСтавка, которая нам нужна для расчета вечерних часов + пользователю не надо для расчета вечерних часов указывать в документе начисление вид расчета ВечерниеЧасы, но Гакусей (а он спец в ЗУПе и теперь и по платформе) настаивает, что вечерние часы - это отдельный вид расчета. Тогда не понятно, как расчитается ТарифнаяСтавка для вечерних часов? (формула НачальноеЗначениеОклада/КоличествоРабочихЧасов) - необходимо будет тогда для вечерних часов также подтягивать НачальноеЗначениеОклада, а КоличествоРабочихЧасов брать КоличествоЧасовПериодДействия, а если пользователь ошибется и укажет для Оклада и для вечерних часов разные графики? - КоличествоРабочихЧасов рассчитается неверно...
-
Тогда не понятно, как расчитается ТарифнаяСтавка для вечерних часов? (формула НачальноеЗначениеОклада/КоличествоРабочихЧасов) - необходимо будет тогда для вечерних часов также подтягивать НачальноеЗначениеОклада, а КоличествоРабочихЧасов брать КоличествоЧасовПериодДействия, а если пользователь ошибется и укажет для Оклада и для вечерних часов разные графики? - КоличествоРабочихЧасов рассчитается неверно...
Тогда добавить ресурс отработано вечерних часов в осн начисления, и реквизит часовая ставка (или расчетно её получать) Вечерние час в доп начислениях без периода действия. По базе получаем - сумму вечерних часов, и часовую ставку.
-
Тогда не понятно, как расчитается ТарифнаяСтавка для вечерних часов? (формула НачальноеЗначениеОклада/КоличествоРабочихЧасов) - необходимо будет тогда для вечерних часов также подтягивать НачальноеЗначениеОклада, а КоличествоРабочихЧасов брать КоличествоЧасовПериодДействия, а если пользователь ошибется и укажет для Оклада и для вечерних часов разные графики? - КоличествоРабочихЧасов рассчитается неверно...
Тогда добавить ресурс отработано вечерних часов в осн начисления, и реквизит часовая ставка (или расчетно её получать) Вечерние час в доп начислениях без периода действия. По базе получаем - сумму вечерних часов, и часовую ставку.
В этом варианте мне кажется не очень правильно для оплаты по виду расчета, который обладает какой-то протяженностью во времени и по идее не имеет базы мы отключаем период действия и включаем базу.. Как то это всё нелогично...
Мне всё-таки больше нравится вариант с видом расчета ВечерниеЧасы, а расчет суммы как КоличествоВечернихЧасовФактическийПериодДействия * (НачальныйОклад/КоличествоЧасовПериодДействия). Отключать период действия для вечерних часов точно не стоит, возможно их еще будет что то вытеснять (в задаче 3 где встречалось это условие, еще и командировка).
-
В этом варианте мне кажется не очень правильно для оплаты по виду расчета, который обладает какой-то протяженностью во времени и по идее не имеет базы мы отключаем период действия и включаем базу.. Как то это всё нелогично...
Мне всё-таки больше нравится вариант с видом расчета ВечерниеЧасы, а расчет суммы как КоличествоВечернихЧасовФактическийПериодДействия * (НачальныйОклад/КоличествоЧасовПериодДействия). Отключать период действия для вечерних часов точно не стоит, возможно их еще будет что то вытеснять (в задаче 3 где встречалось это условие, еще и командировка)
Командировка вытеснит оклад, и у вечерних часов база будет нулевая по вечерним часам.
А вот на счет логичности, не знаю, практический опыт проектирования расчетных задач - отсутствует. С моей стороны добавление вечерних часов пользователем означает включение для сотрудника такой доплаты, а базовый период - собственно за какой период идёт доплата.
Если попадётся на экзамене, попробую сделать так ради интереса.
-
И еще закрались сомнения - по условию "За каждый час работы в вечернее время сотрудники получают оплату на 50% больше их часовой ставки по окладу", то есть мы должны для вечерних часов делать оплату как КоличествоЧасов * 1.5 часовой ставки, но тогда необходимо будет при оплате по окладу рассчитывать только 6 часов. Или я уже чересчур заморачиваюсь...
-
Может, все-таки сделать новый ВР "Оплата вечерние часы" с графиком пн,ср,пт, Период действия равен базовому, база Оклад, и считать База*50%*(вечерние часы / всего рабочих часов) ?
Выглядит вполне логично, учитывая, что на экзамене проверяют умение работать с начислениями, а не с мутными заумными формулами и взаимосвязями
Если есть опасение что пользователь ошибется при вводе данных, то в обработке проведения НЗ можно автоматически создавать строку с "Оплата вечерних часов" для каждой строки с "Оклад" с теми же ПДНачало и ПДКонец, только с Графиком "Пн,ср,пт"
-
Почему в ресурсе 0.4? Я так понял, если реализуем вытеснение оклада опозданиями, то в графике два ресурса - один фиксирует единицы каждые 15 минут (для подсчета количества пятнадциминутных опозданий), а во втором - количество часов в интервале, т.е. 0.25. для подсчета отработанных часов оклада.
Косяк. Да. Заполнять по 0.25
-
Чтобы отвлечься пока от вечерних часов, реализовал задачу по формированию документу ВыплатаЗарплаты. Новый регистр остатков ВзаиморасчетыССотрудниками (Сотрудник, Подразделение, ВидРасчета, Сумма). В обработке проведения документа НачислениеЗарплаты делаем в него приход, в новом документе ВыплатаЗарплаты расход + отчет Расчетно-платежная ведомость - достаточно простой на виртуальном регистре ВзаиморасчетыССотрудникамиОстаткиИОбороты.
Единственное, что смущает - в документе ВыплатаЗарплаты кнопка Заполнить подтягивает остатки из регистра и заполняет по ним табличную часть, вопрос - должны ли эти остатки получаться на момент времени документа или достаточно будет получить их на дату документа. А то у меня получилась конструкция, которая мне не очень нравится: Запрос.УстановитьПараметр("МоментИтогов", РеквизитФормыВЗначение("Объект").МоментВремени()); Решеная задача во вложении, буду рад конструктивной критике.
-
Реализовал также задачу программной записи перерасчетов в 5 и 6 билетах, где данные для надбавки рассчитываются по данным из регистра бухглатерии и накопления сооответственно. Расскажу на примере 5 билета. В чем загвоздка - при добавлении перерасчета в регистр расчета система требует чтобы ПВР этого регистра был с базой. Может как то можно обойтись без этого, у меня не получилось. Раз уж пошла такая пьянка, появилась мысль - включить базу для ПВР и регистра, и в появившихся полях регистра БазовыйПериодНачало и БазовыйПериодКонец сохранять даты периода, за которые мы получаем данные из регистра накопления и бухгалтерии, но выяснилось, что для перерасчета достаточно только для ПВР указать зависимость от базы, тогда смысла включать базу для регистра только для того, чтобы работать с полями БазовыйПериодНачало и БазовыйПериодКонец нет, в связи с чем оставил только зависимость по базе для ПВР.
Реализацию делал в модуле набора записей - в процедуре ПриЗаписи делал проверку, что наборЗаписей не пустой, затем запрос, в котором сцеплял данные из регистра ДвиженияССубконто (отбор по документу- Отбор.Регистратор.Значение) и регистра расчета допначисления.
На что следует обратить внимание (это описано и на сайте ИТС) при получении запроса для записи в перерасчеты необходимо обеспечить уникальность записей (если могут быть задвоения, то Различные в запросе), также необходимо проверять не присутствуют ли записи, которые мы получаем в запросе, уже в таблице перерасчетов (для этого необходимо соединение в запрос с таблицей перерасчетов и в условии ОбъектПерерасчетов Есть Null)
Выкладываю 5 билет на суд общественности.
-
Ребят, по поводу 2 пункта - учет опозданий. Я так понял из обсуждений, что - делаем ресурс с фиксацией 15 минуток. В ПВР создаем ВР Штраф. ПВР использует период действия. Создаем РР Удержания, связываем его с РС ГрафикиРаботы. По идее должен быть расчет факт времени невыхода?
-
Ребят, по поводу 2 пункта - учет опозданий. Я так понял из обсуждений, что - делаем ресурс с фиксацией 15 минуток. В ПВР создаем ВР Штраф. ПВР использует период действия. Создаем РР Удержания, связываем его с РС ГрафикиРаботы. По идее должен быть расчет факт времени невыхода?
В регистре сведений графиков работ - два ресурса КоличествоЧасов и КоличествоПятнадцитиминуток, день разбит по 15минутным интервалом - с 8.15 по 16.00, и в каждой записи количество часов равно 0.25, количество интервалов равно 1.
Дальше либо в Основных начислениях вид расчета, который вытестняет оплату по окладу (или тарифу) и он же рассчитывает штраф за каждые 15 минут либо в основных вид расчета, который вытесняет оклад и накапливает в ресурсе количество пятнадциминуток, а в удержаниях вид расчета, для которого базой будет вид Расчета фиксирующий опоздания и в котором будет рассчитываться сумма удержания.
-
Ребят, по поводу 2 пункта - учет опозданий. Я так понял из обсуждений, что - делаем ресурс с фиксацией 15 минуток. В ПВР создаем ВР Штраф. ПВР использует период действия. Создаем РР Удержания, связываем его с РС ГрафикиРаботы. По идее должен быть расчет факт времени невыхода?
В регистре сведений графиков работ - два ресурса КоличествоЧасов и КоличествоПятнадцитиминуток, день разбит по 15минутным интервалом - с 8.15 по 16.00, и в каждой записи количество часов равно 0.25, количество интервалов равно 1.
Дальше либо в Основных начислениях вид расчета, который вытестняет оплату по окладу (или тарифу) и он же рассчитывает штраф за каждые 15 минут либо в основных вид расчета, который вытесняет оклад и накапливает в ресурсе количество пятнадциминуток, а в удержаниях вид расчета, для которого базой будет вид Расчета фиксирующий опоздания и в котором будет рассчитываться сумма удержания.
в общем единственный момент с котором не разобрался - был именно 15-минутки. Сдавал 20 июля. Попался 5 билет. Сделал на 1 ресурсе в РС, который разбит по 15 мин. правда с
8:00 до 16:00. В основных начислениях оклад и штраф, который вытесняет оклад. В целом все работоспособно оказалось. Делал на лету, т.к. повторюсь - не понял этот момент при подготовке и понадеялся на авось. Как придет результат - более подробно отпишусь в соотв. ветке форума
-
А вот какой вопрос возник: зачем делать график по 15 минут, как некоторые указывали еще в обсуждении задачи 3.24, ведь вытеснения по условию задачи нет?
А если считать время опозданий, то предлагаю проверить такой вариант:
Есть записи по 15 минут в регистре сведений, есть опоздание у работника, например, с 8:00 по 8:17.
Проводим документ и в запросе из видим, что по данным графика опоздание уже 30 минут.
Т.е. для корректного подсчета времени опоздания нужно делать регистр поминутно, но здесь другой вопрос, а нужен ли такой монстр при отсутствии вытеснений, да и ограничение учебной версии по количеству записей в регистре никто не отменял.
А что если просто создать еще один документ, в котором указать когда сотрудник должен прийти на работу и когда пришел, сравнивать и если больше 15 минут, тогда начислять штраф?
-
Задача СПР 6 билета.
[вложение удалено администратором]
-
Ребят, по поводу 2 пункта - учет опозданий. Я так понял из обсуждений, что - делаем ресурс с фиксацией 15 минуток. В ПВР создаем ВР Штраф. ПВР использует период действия. Создаем РР Удержания, связываем его с РС ГрафикиРаботы. По идее должен быть расчет факт времени невыхода?
В регистре сведений графиков работ - два ресурса КоличествоЧасов и КоличествоПятнадцитиминуток, день разбит по 15минутным интервалом - с 8.15 по 16.00, и в каждой записи количество часов равно 0.25, количество интервалов равно 1.
Дальше либо в Основных начислениях вид расчета, который вытестняет оплату по окладу (или тарифу) и он же рассчитывает штраф за каждые 15 минут либо в основных вид расчета, который вытесняет оклад и накапливает в ресурсе количество пятнадциминуток, а в удержаниях вид расчета, для которого базой будет вид Расчета фиксирующий опоздания и в котором будет рассчитываться сумма удержания.
в общем единственный момент с котором не разобрался - был именно 15-минутки. Сдавал 20 июля. Попался 5 билет. Сделал на 1 ресурсе в РС, который разбит по 15 мин. правда с
8:00 до 16:00. В основных начислениях оклад и штраф, который вытесняет оклад. В целом все работоспособно оказалось. Делал на лету, т.к. повторюсь - не понял этот момент при подготовке и понадеялся на авось. Как придет результат - более подробно отпишусь в соотв. ветке форума
Добрый день.
Я так понимаю результат вам пришел, не могли бы вы более подробно расписать решение с 15 минутками? Попалось на экзамене именно это условие, не смог его реализовать.
-
Есть мнение, что нужно реализовывать так:
1. Заводим график 15 минутками, то есть не по 1 записи на каждый день, а 32, в каждой по 0.25 (для 8-ми часового рабочего дня). Соответственно тип измерения "Дата"РС ГрафикиРаботы меняем на Дата, состав Дата+Время.
Делаете на форме реквизиты ВремяНачала и ВремяОкончания типа Дата, состав Время.
Вот модуль обработки Заполнение графика:
Процедура ЗаполнитьГрафик(ДатаНачала, ДатаОкончания, ВыходныеДни, Сотрудник, Подразделение, ВремяНачала, ВремяОкончания) Экспорт
Набор = РегистрыСведений.ГрафикиРаботы.СоздатьНаборЗаписей();
Набор.Отбор.Сотрудник.Установить(Сотрудник);
Набор.Отбор.Подразделение.Установить(Подразделение);
Набор.Прочитать();
Дат = ДатаНачала;
Пока Дат <= ДатаОкончания Цикл
Врем = дата(1,1,1)+ (Дат - НачалоДня(Дат));
Если Врем >=ВремяНачалаРаботы и Врем <= ВремяОкончанияРаботы Тогда
Запись = Набор.Добавить();
Запись.Дата = Дат;
Запись.Сотрудник = Сотрудник;
Запись.Подразделение = Подразделение;
Если Найти(ВыходныеДни, Строка(ДеньНедели(Дат))) Тогда
Запись.Значение = 0;
Иначе
Запись.Значение = 0.25;
КонецЕсли;
КонецЕсли;
Дат = Дат + 900;
КонецЦикла;
Набор.Записать();
КонецПроцедуры
2. ВР Оклад и ВР Опоздание оба в ПВР Основные начисления, у которого ПД. Опоздание вытесняет Оклад. Однако, тут подводный камень: ХЗ как правильно - должно ли Опоздание вытеснять Оклад или нет? По логике, ты получаешь как обычно, а потом из этого "обычно" вычитают штраф... Но! Это ж экзамен, надо продемонстрировать умение работать с вытеснением.. так что я на экзамене сделаю Опоздание вытесняющим :)))
3. Соответственно, в документе НЗ тип реквизитов ДатаНачала и ДатаОкончания не просто Дата, а Дата+Время.
4. Вводите, скажем: Иванов, Оклад, с 01.01.2016 09:00:00 по 31.01.2016 23:59:59
5. Ну и Иванов, Опоздание, с 05.01.2016 09:00:00 по 05.01.2016 09:59:59
6. Дальше в Расчете считаете Оклад, ДанныеГрафика.ЗначениеФактическийПериодДействия, у вас там получится меньше, вытеснение будет Опозданием.
7. Ну и Опоздания тоже, ДанныеГрафика.ЗначениеФактическийПериодДействия, делите на 0.25, умножаете на 100 руб
P.S. Сам я этот алгоритм в бою не испробовал, так как сам первый раз иду сдаваться в эту пятницу...
Попалось на экзамене именно это условие, не смог его реализовать.
А что, за не реализацию всего лишь одного этого условия уже сразу несдача?
-
А что, за не реализацию всего лишь одного этого условия уже сразу несдача?
Не, 1 балл скорее всего скинут. Просто в других местах могут еще наковырять мелких ошибок, тогда пролететь можешь.
-
Есть мнение, что нужно реализовывать так:
1. Заводим график 15 минутками, то есть не по 1 записи на каждый день, а 32, в каждой по 0.25 (для 8-ми часового рабочего дня)
Делаете на форме реквизиты ВремяНачала и ВремяОкончания типа дата, состав время
Вот модуль обработки Заполнение графика:
Процедура ЗаполнитьГрафик(ДатаНачала, ДатаОкончания, ВыходныеДни, Сотрудник, ВремяНачала, ВремяОкончания) Экспорт
Набор = РегистрыСведений.ГрафикиРаботы.СоздатьНаборЗаписей();
Набор.Отбор.Сотрудник.Установить(Сотрудник);
Дат = ДатаНачала;
Пока Дат <= ДатаОкончания Цикл
Врем = Дата(1,1,1) + (Дат - НачалоДня(Дат));
Если Врем >= ВремяНачала И Врем <= ВремяОкончания Тогда
Запись = Набор.Добавить();
Запись.Дата = Дат;
Запись.Сотрудник = Сотрудник;
Если Найти(ВыходныеДни, Строка(ДеньНедели(Дат))) Тогда
Запись.Часы = 0;
Иначе
Запись.Часы = 0.25;
КонецЕсли;
КонецЕсли;
Дат = Дат + 900;
КонецЦикла;
Набор.Записать();
КонецПроцедуры
2. ВР Оклад и ВР Опоздание оба в ПВР Основные начисления, у которого ПД. Опоздание вытесняет Оклад.
3. Соответственно, в документе НЗ тип реквизитов ДатаНачала и ДатаОкончания не просто Дата, а Дата+Время.
4. Вводите, скажем: Иванов, Оклад, с 01.01.2016 09:00:00 по 31.01.2016 18:59:59
5. Ну и Иванов, Опоздание, с 05.01.2016 09:00:00 по 05.01.2016 10:00:00
6. Дальше в Расчете считаете Оклад, ДанныеГрафика.ФактическийПериодДействия, у вас там получится меньше, вытеснение будет Опозданием.
7. Ну и Опоздания тоже, ДанныеГрафика.ФактическийПериодДействия,делите на 0.25, умножаете на 100 руб
P.S. Сам я этот алгоритм в бою не испробовал, так как сам первый раз иду сдаваться в эту пятницу...
Попалось на экзамене именно это условие, не смог его реализовать.
А что, за не реализацию всего лишь одного этого условия уже сразу несдача?
Спасибо за развернутый ответ! Нет конечно, у меня набралось порядком ошибок тогда. Точно уже не вспомню что, сдавал в ноябре прошлого года. 25.10.16 снова пойду.
-
25.10.16 снова пойду.
Я тоже если завтра не сдам, пойду 20.10.16 или 03.11.16 повторно сдаваться.
Буду штудировать билеты, ну и мандража, надеюсь, во второй раз поменьше будет.
-
Мне кажется, что условие про штрафы за 15 минут опоздания в СПР из пятого билета сильно усложняют.
Может можно сделать проще?
В ПВР "Удержания" завести вид расчета "Штраф" (он там в принципе уже есть предопределенный).
В документ "Начисление зарплаты" добавить ТЧ "Удержания".
В реквизит "Размер" ТЧ "Удержания" заносить количество минут опоздания.
Затем, в модуле документа добавлять запись в регистр расчета "Удержания" - писать измерения и количество минут опоздания.
А в общем модуле сделать расчет суммы штрафа в зависимости от количества целых пятнадцатиминуток.
в Основные начисления смысла засовывать штраф не вижу, так как:
- вроде не надо вытестение, иначе оклад за этот период не начислится (а это из условий задачи никаким образом не следует).
- вроде не нужен период действия, так как сумма штрафа зависит только от количества минут опоздания.
Все ИМХО, конечно.
Вообще на экзамене так и делала, но не сдала, поэтому не понятно, допустимо решать таким образом или нет.
На экзамене вообще не сделала задачу по бизнес-процессам, в отчете по СПР не добавила отбор по периоду, в бухучете не добавила признак учета субконто "Суммовой".
Результат:
Оценка: 2
Экзамен считается сданным при оценке больше или равной 3.
Комментарий:
В БУ списание по средней по номенклатурной позиции корректно не реализовано (нужно было использовать признак учета субконто). Считается, что бухгалтерская часть задачи не решена.
Нет привязки графика к подразделению
Т.е. задачу по бухучету полностью не засчитали из-за отсутствия признака учета субконто и дальше проверять не стали. Хотя, возможно проверили ОУ и СПР, из комментария это не понятно.
"Нет привязки графика к подразделению" - не поняла, что нужно было сделать, надо ещё раз задачу решить :(
-
Мне кажется, что условие про штрафы за 15 минут опоздания в СПР из пятого билета сильно усложняют.
Нельзя. Ваш метод первым делом пришел и мне в голову: дешево и сердито. Увы, Белоусов (автор сборника задач и экзаменатор) в ответ на вопрос можно ли так делать ответил - "а может вы и отпуск так считать будете? Колво дней вручную впишете? Вам было написано в билете используется метод отклонений!"
Так что думаю (надеюсь) что правильно делать так как я написал выше. К сожалению, мне эта задача сегодня на экзамене не попалась (досталось неоднократное изменение оклада).
Так что истину предстоит узнать потомкам:)))
-
я чет не пойму. зачем штрафы в Основные Начисления? заводим документ Опоздание и делаем движение в оборотные регистр (количество минут). Или по правильному нужно в регистр сведений ГрафикРаботы добавить ресурс Опоздания (минуты) и туда руками заносить? Кто знает как точно делать надо???? Не хочу опять на пересдачу
Мне кажется, что условие про штрафы за 15 минут опоздания в СПР из пятого билета сильно усложняют.
Нельзя. Ваш метод первым делом пришел и мне в голову: дешево и сердито. Увы, Белоусов (автор сборника задач и экзаменатор) в ответ на вопрос можно ли так делать ответил - "а может вы и отпуск так считать будете? Колво дней вручную впишите? Вам было написано в билете используется метод отклонений!"
Так что думаю (надеюсь) что правильно делать так как я написал выше. К сожалению, мне эта задача сегодня на экзамене не попалась (досталось неоднократное изменение оклада).
Так что истину предстоит узнать потомкам:)))
-
Мне кажется, что условие про штрафы за 15 минут опоздания в СПР из пятого билета сильно усложняют.
Нельзя. Ваш метод первым делом пришел и мне в голову: дешево и сердито. Увы, Белоусов (автор сборника задач и экзаменатор) в ответ на вопрос можно ли так делать ответил - "а может вы и отпуск так считать будете? Колво дней вручную впишите? Вам было написано в билете используется метод отклонений!"
ОК, вы меня убедили фразой про метод отклонений :)
-
а через сколько как правило приходит результат по экзамену?
-
а через сколько как правило приходит результат по экзамену?
Я сдавала 26 сентября, результат пришел 6 октября.
Коллеги сдавали, говорили, что где-то через 2 недели приходит результат :(
Это про дистанционную сдачу, естественно.
-
а через сколько как правило приходит результат по экзамену?
Я последний раз сдавал вместе с коллегами в конце прошлого года (то ли конец ноября, то ли начало декабря). Так вот ответ шел МЕСЯЦ! Мы там извелись все).
Возможно причина в приближающемся НГ, а может тогда только новую систему в тестовом режиме запускали (1с-Гуру если я не ошибаюсь).
-
Реализовал также задачу программной записи перерасчетов в 5 и 6 билетах, где данные для надбавки рассчитываются по данным из регистра бухглатерии и накопления сооответственно. Расскажу на примере 5 билета. В чем загвоздка - при добавлении перерасчета в регистр расчета система требует чтобы ПВР этого регистра был с базой. Может как то можно обойтись без этого, у меня не получилось. Раз уж пошла такая пьянка, появилась мысль - включить базу для ПВР и регистра, и в появившихся полях регистра БазовыйПериодНачало и БазовыйПериодКонец сохранять даты периода, за которые мы получаем данные из регистра накопления и бухгалтерии, но выяснилось, что для перерасчета достаточно только для ПВР указать зависимость от базы, тогда смысла включать базу для регистра только для того, чтобы работать с полями БазовыйПериодНачало и БазовыйПериодКонец нет, в связи с чем оставил только зависимость по базе для ПВР.
Реализацию делал в модуле набора записей - в процедуре ПриЗаписи делал проверку, что наборЗаписей не пустой, затем запрос, в котором сцеплял данные из регистра ДвиженияССубконто (отбор по документу- Отбор.Регистратор.Значение) и регистра расчета допначисления.
На что следует обратить внимание (это описано и на сайте ИТС) при получении запроса для записи в перерасчеты необходимо обеспечить уникальность записей (если могут быть задвоения, то Различные в запросе), также необходимо проверять не присутствуют ли записи, которые мы получаем в запросе, уже в таблице перерасчетов (для этого необходимо соединение в запрос с таблицей перерасчетов и в условии ОбъектПерерасчетов Есть Null)
Выкладываю 5 билет на суд общественности.
Решал 6 билет. Там тоже программный перерасчет.
Вопрос, почему у вас в запросе используется условия, вместо параметров вирт. таб. РБ
| РегистрБухгалтерии.Управленческий.ДвиженияССубконто КАК УправленческийДвиженияССубконто
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрРасчета.ДопНачисления КАК ДопНачисления
....
|ГДЕ
....
| И УправленческийДвиженияССубконто.Регистратор = &Регистратор
| И УправленческийДвиженияССубконто.СчетДт = &СчетПокупатели
| И УправленческийДвиженияССубконто.СчетКт = &СчетПрибыли
-
Решал 6 билет. Там тоже программный перерасчет.
Вопрос, почему у вас в запросе используется условия, вместо параметров вирт. таб. РБ
Молодой, глупый был))) Дело в том, что я почему-то думал, что таблица ДвиженияССубконто физическая, а не виртуальная и благополучно её использовал для решения задачи, ну и из-за этой же мысли устанавливал условия, а не задавал параметры виртуальной таблицы.
Вообще здесь не к чему использование виртуальной таблицы, необходимо в запрос передавать таблицу значений, полученную из набора записей. Для этого есть замечательный метод выгрузить для набора записей.
-
2. С условием "за каждые целые 15 минут опоздания начисляется штраф" всё сложнее. Подобное обсуждалось при решении задачи 3.24 (http://forum.chistov.pro/index.php?topic=1182.0) и в ветке "Результаты сдачи экзаменов", но к окончательному решению нигде не пришли, кто-то предлагает вводить количество 15 минуток опозданий, кто-то рассчитывать минуты опоздания и делить на 15, кто-то в графиках фиксировать не часы, а 15 минутки. Как Вы считаете (или успешно реализовали на экзамене) какой алгоритм здесь правильный?
Я не понимаю а что экзаменаторы сами не могут пояснить как следует решать это их дополнительное условие, или они желают поиздеваться?
-
Добрый день! Если я правильно понял задача с 15-минутками так больше никому и не попалась? Какое-же все-таки решение использовать?
-
Добрый день! Если я правильно понял задача с 15-минутками так больше никому и не попалась? Какое-же все-таки решение использовать?
Посмотрел лекции Белоусова: Говорит для штрафа отдельный график + сам штраф в ОН вместе с окладом.
Я бы вот так решал. Подробнее решение описывает фриз в ветке Результаты сдачи
-
Понял, спасибо!
-
Добрый день! Если я правильно понял задача с 15-минутками так больше никому и не попалась? Какое-же все-таки решение использовать?
Мне попалась недавно. Сдача 22 сент. Я не успела много чего реализовать, включая и это условие. До самого экзамена не заморачивалась с дополнениями, увидела 15-ти минутки только на экзамене. В голову пришло решение, которое описывала Rendalina в этой ветке выше. Вот так и сделала бы. По двум причинам. 1. Готовилась по методичкам (теория СПР + решение большой задачи), в ней штраф так и реализовывался, несмотря на метод отклонений (он был для других ВР, отпуска например). 2. был опыт работы на предприятии с таким дебильным штрафом, навеяло))
Тем более штраф - он и есть штраф. Фиксированный. Это не командировка какая-нибудь, где имеет смысл вытеснять оклад, ведь идет начисление совсем другое. А тут фиксированное удержание. Если будем вытеснять из оклада, то помимо своего штрафа за опоздание, пострадавший будет еще и частью оклада расплачиваться :) Надеюсь понятно изъяснила свои мысли.
Конечно! возможно, я неправа :) И пока сама не знаю, какой вариант выбрать для решения. Тут в ветке про какого-то Белоусова писали (а кто это? принимающий?), что надо решение....ну вы в курсе ;)
-
Коллеги, прощу прощения если задам дурацкий вопрос, есть ли информация, дополнительные задания на дистанционной сдаче, они как то известны по билетам (ну т.е. например в билете №3 будет доп про вечерние часы, а в билете №5 - фиксация штрафа за 15 минут), или любой доп может всплыть в любом билете?
-
У меня информация только по первым 6 билетам для дистанционного экзамена (на очном билеты выглядят по-другому). Собирал по информации от отписавшихся здесь сдававших.
Во всех СПР убрали условие про данные за разные расчетные периоды (изменено на текущий).
Билет 1.
СПР.
1. Добавдено условие "Сделать на форме кнопу "Рассчитать", при нажатии которой будет производится расчёт и сразу же результаты должны отображаться в ТЧ документа."
Билет 2.
БУ.
1. Добавлено условие "При проведении документа (расходная накладная) анализируется наличие этого товара на указанном в шапке документа складе. Если товара недостаточно документ не проводится."
2. Убрали условие "При распределении по товарам затраты распределяются пропорционально их проданному количеству."
3. В отчете в колонке Сумма затрат суммы рассчитываются только по группировке Проект. По количеству рассчитывать не надо.
СПР.
1. Добавдено условие "Период (премии) задается с точностью до дня в документе «Начисление зарплаты»."
2. Добавдено условие "Вместо премии, за любой отработанный день, сотруднику может быть выплачена произвольная сумма денег."
3. Убрали условие "Создать отчет «Перерасчет зарплаты», в котором пользователь должен увидеть записи регистра расчета, которые возможно требуется пересчитать."
4. Убрали условие "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется."
5. Добавдено условие "В конфигурации необходимо создать документ «Зарплата к выплате». Документ формируется по конкретному подразделению. Предусмотреть возможность автоматического заполнения документа по остаткам невыплаченных сумм."
6. Добавлен отчет с шапкой "Расчетно-платежная ведомость № 1 за январь 2010 года по подразделению «Бухгалтерия»", с колонками Сотрудник, Вид расчета, Нач. сальдо, Начислено, Выплачено, Кон. сальдо. Итоги по вертикали.
Билет 3.
СПР.
1. Добавдено условие "По понедельникам, средам и пятницам по 2 часа времени уходит на вечерние часы. Часовая ставка за каждый вечерний час на 50% больше часовой ставки оклада."
2. Добавдено условие "Вечерние часы (командировка) рассчитываются также как и для оклада." Но в решениях сдававших не видел, чтобы кто-то реализовывал вечерние часы в командировке.
Билет 4.
СПР.
1. Убрали условие "Все сотрудники работают по пятидневному графику работы, однако в решении необходимо предусмотреть возможность работы по нескольким различным графикам."
2. Добавдено условие "Каждый сотрудник может работать одновременно в нескольких подразделениях компании, т.е. совместительство допускается."
3. Добавдено условие "Сотрудники каждого подразделения работают в три смены по графику «Сутки через двое»."
4. Убрали условие "Тарифная ставка в расчетном периоде не меняется. Тарифная ставка может меняться каждый день"
5. Добавдено условие "В течение расчетного периода тарифная ставка задается для каждой смены отдельно и может меняться каждый день"
6. Убрали условие "В документе Начисление Зарплаты пользователь вводит значение тарифной ставки вручную. Сотрудники работают по сменному графику «Сутки через двое»."
7. Добавдено условие "В информационной базе необходимо хранить историю ее изменения."
8. Добавдено условие "Необходимо предоставить пользователю возможность самостоятельно создавать новые виды расчетов и привязывать их к существующим алгоритмам расчета."
9. Добавлен отчет "Для анализа полученных сотрудниками предприятия премий в конфигурации необходимо предусмотреть отчет следующего вида:". Колонки Подразделение, Сотрудник, % премии, Сумма премии. Отчет должен быть построен только за определенный календарным месяц.
БП.
1. Задача заменена задачей БП из билета 10.
Билет 5.
СПР.
1. Добавдено условие "Если сотрудник опоздал на работу, то за каждые целые 15 минут опоздания начисляется штраф в размере 100 рублей."
БП.
1. Есть какие-то отличия, какие не знаю.
Билет 6.
СПР.
1. Добавдено условие "Сумма оплат должна быть получена по данным бухгалтерского учета с использованием следующей проводки: Дт «Касса» - Кт «Покупатели» на сумму оплат. Считать, что после расчета сумма оплат корректировке не подлежит."
2. Убрали условие "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца поделенная на количество отработанных дней в трех предыдущих месяцах."
3. Добавдено условие "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца поделенная на количество рабочих дней в трех предыдущих месяцах."
4. Добавлен отчет "Создать отчет «Перерасчеты зарплаты», в котором пользователь должен увидеть записи регистра расчета, которые возможно требуется пересчитать. Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров." Колонки Объект перерасчета, Вид расчета, …
5. Убрали условие "Механизм перерасчетов в рамках данной задачи использовать не надо"
6. Добавдено условие "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется."
БП.
1. Задача заменена задачей БП из билета 14.
-
Что-то из 4го билета СПР совсем жесть.
А как реализовывать:
Добавдено условие "Необходимо предоставить пользователю возможность самостоятельно создавать новые виды расчетов и привязывать их к существующим алгоритмам расчета."
-
Что-то из 4го билета СПР совсем жесть.
А как реализовывать:
Добавдено условие "Необходимо предоставить пользователю возможность самостоятельно создавать новые виды расчетов и привязывать их к существующим алгоритмам расчета."
http://forum.chistov.pro/index.php?topic=3653.msg53854#msg53854
-
Благодарю за ссылку!
А что скажете про
4. Добавлен отчет "Создать отчет «Перерасчеты зарплаты», в котором пользователь должен увидеть записи регистра расчета, которые возможно требуется пересчитать. Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров." Колонки Объект перерасчета, Вид расчета, …
5. Убрали условие "Механизм перерасчетов в рамках данной задачи использовать не надо"
6. Добавдено условие "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется."
? мне кажется или это как раз тот самый "Програмная запись", что делается в модуле набора записей регистра бухгалтерии?
-
мне кажется или это как раз тот самый "Програмная запись", что делается в модуле набора записей регистра бухгалтерии?
В ветке билета 6 есть ссылка на вариант решения от Гакусей http://forum.chistov.pro/index.php?topic=3670.msg53971#msg53971.
-
БП из 14-го билета перенесли в 6-й при дистанционной сдаче.
-
Билет 2
"2. Убрали условие "При распределении по товарам затраты распределяются пропорционально их проданному количеству.""
А добавили условие как надо распределять затраты?
-
Всем привет.
Пункт 2 билета 2 означает, что нужно добавить третий вид расчета ("премия суммой") и настроить вытеснение ("премия суммой" вытесняет "премию процентом")?
-
В билете 4 убрали надбавку. Премия руководителю рассчитывается от тарифной ставки. Тарифная ставка устанавливается для смены
-
Что-то из 4го билета СПР совсем жесть.
А как реализовывать:
Добавдено условие "Необходимо предоставить пользователю возможность самостоятельно создавать новые виды расчетов и привязывать их к существующим алгоритмам расчета."
Свое решение положил в теме 4 билета, http://forum.chistov.pro/index.php?topic=3653.165
-
Здравствуйте!
Хотел приподнять тему по поводу документа "Выплата зарплаты".
Я могу от себя сказать следующее.
В курсе Гончарова для подготовки к экзамену "1С Специалист по платформе"
дается для самостоятельного решения задача.
Там в задаче на периодические расчеты есть начисления и удержания (штрафы).
И там требуется создать отчет с полями:
Сотрудник, К начислению, К удержанию, К выплате.
И по этому поводу Гончаров говорит, что поле "К выплате" -
чисто расчетное, это разница начислений и удержаний.
Что автоматизировать выплату зарплаты в данной задаче не требуется,
никакого документа "Выплата зарплаты" создавать не надо.
Если кто что знает про другие варианты на экзамене - отзовитесь.
-
Здравствуйте!
Хотел приподнять тему по поводу документа "Выплата зарплаты".
Я могу от себя сказать следующее.
В курсе Гончарова для подготовки к экзамену "1С Специалист по платформе"
дается для самостоятельного решения задача.
Там в задаче на периодические расчеты есть начисления и удержания (штрафы).
И там требуется создать отчет с полями:
Сотрудник, К начислению, К удержанию, К выплате.
И по этому поводу Гончаров говорит, что поле "К выплате" -
чисто расчетное, это разница начислений и удержаний.
Что автоматизировать выплату зарплаты в данной задаче не требуется,
никакого документа "Выплата зарплаты" создавать не надо.
Если кто что знает про другие варианты на экзамене - отзовитесь.
Если вы говорите только об отчете, то соответсвенно никакого документа не надо, но если в условии задачи явно указано что необходимо создать документ "ЗапрлатаКВыплате" то он обязательно должен быть
-
было бы интересно текст условия реальной задачи увидеть. Если есть, конечно.
-
У меня информация только по первым 6 билетам для дистанционного экзамена (на очном билеты выглядят по-другому). Собирал по информации от отписавшихся здесь сдававших.
Во всех СПР убрали условие про данные за разные расчетные периоды (изменено на текущий).
Билет 2.
СПР.
5. Добавдено условие "В конфигурации необходимо создать документ «Зарплата к выплате». Документ формируется по конкретному подразделению. Предусмотреть возможность автоматического заполнения документа по остаткам невыплаченных сумм."
в этой же ветке написали, что по 2 билету добавлено условие. Чем вам не условие реальной задачи
-
Evgenich, спасибо!
Всё, увидел.
Да, здесь прямым текстом - никуда не денешься,
надо делать документ на выплату.
-
У меня информация только по первым 6 билетам для дистанционного экзамена (на очном билеты выглядят по-другому). Собирал по информации от отписавшихся здесь сдававших.
Во всех СПР убрали условие про данные за разные расчетные периоды (изменено на текущий).
Билет 5.
СПР.
1. Добавдено условие "Если сотрудник опоздал на работу, то за каждые целые 15 минут опоздания начисляется штраф в размере 100 рублей."
БП.
1. Есть какие-то отличия, какие не знаю.
Народ, кто-нибудь знает, какие отличия есть в Билете № 5, в задаче по Бухгалтерскому учету?
-
У меня информация только по первым 6 билетам для дистанционного экзамена (на очном билеты выглядят по-другому). Собирал по информации от отписавшихся здесь сдававших.
Во всех СПР убрали условие про данные за разные расчетные периоды (изменено на текущий).
Билет 5.
СПР.
1. Добавдено условие "Если сотрудник опоздал на работу, то за каждые целые 15 минут опоздания начисляется штраф в размере 100 рублей."
БП.
1. Есть какие-то отличия, какие не знаю.
Народ, кто-нибудь знает, какие отличия есть в Билете № 5, в задаче по Бухгалтерскому учету?
БП <> БУ
-
Sims, поясни, что это значит.
-
Ты имеешь в виду БП - это бизнес-процесс?
-
Ты имеешь в виду БП - это бизнес-процесс?
В сообщении Clition указано, что есть отличия в БП (бизнес процессах), а не в БУ (бухгалтерском учёте)
-
Спасибо за пояснение !
-
Кто мне скажет . есть ли придирки к написанию модуля в таких документах как приход денег . затраты, расход денег,
где в условии сказано док делает проводку . делал в затратах просто проводку конструктором . без запроса и набора движений с блокировкой.
-
Кто мне скажет . есть ли придирки к написанию модуля в таких документах как приход денег . затраты, расход денег,
где в условии сказано док делает проводку . делал в затратах просто проводку конструктором . без запроса и набора движений с блокировкой.
Если в документе все данные для проводки берутся из самого документа, т.е. не нужно получать данные из регистров и других объектов, то и никаких запросов для проведения делать не требуется. Достаточно будет того кода, который напишет конструктор
-
По поводу использования конструктора запросов могу добавить.
В правилах экзамена сказано, что конфигурация должна работать корректно при наличии дублей строк.
Группировка в запросе решает эту проблему, конструктор запросов - нет.
И ещё.
Будет ошибкой делать следующее.
В приходной накладной, если делаете проверку в цикле,
что бы не приходовать услуги на склад.
Что-то типа "Если Номенлатура.Услуга тогда".
Обращение через точку здесь - это запрос в цикле.
За это минус.
-
По поводу использования конструктора запросов могу добавить.
В правилах экзамена сказано, что конфигурация должна работать корректно при наличии дублей строк.
Группировка в запросе решает эту проблему, конструктор запросов - нет.
И ещё.
Будет ошибкой делать следующее.
В приходной накладной, если делаете проверку в цикле,
что бы не приходовать услуги на склад.
Что-то типа "Если Номенлатура.Услуга тогда".
Обращение через точку здесь - это запрос в цикле.
За это минус.
а как вы решете проблему с дублей строк?
2) можно в табчасти в свойствах отбора у товара указать .чтобы отбирал только товар .в таб часть . зачем условия писать
-
Это Док Приход Денег .
можно же просто конструктором сделать проводку и структурой получить курс на дату
Процедура ОбработкаПроведения(Отказ, Режим)
Движения.Проводки.Записывать = Истина;
Движения.Проводки.Записать();
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрБухгалтерии.Проводки");
ЭлементБлокировки.УстановитьЗначение("Счет", ПланыСчетов.Управленческий.Покупатели);
ЭлементБлокировки.УстановитьЗначение(ПланыВидовХарактеристик.ВидыСубконто.Контрагент, Контрагент);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПроводкиОстатки.Субконто1 КАК Контрагент,
| ПроводкиОстатки.Субконто2 КАК Договор,
| &СуммаНадоСписать КАК СуммаНадоСписать,
| ПроводкиОстатки.СуммаВалютыОстаток * ЕСТЬNULL(КурсыВалютСрезПоследних.Курс, 0) КАК СуммаЗадолженности,
| ПроводкиОстатки.СуммаВалютыОстаток КАК СуммаВалютыОстаток,
| ЕСТЬNULL(КурсыВалютСрезПоследних.Курс, 0) КАК Курс,
| ПроводкиОстатки.Субконто2.ВалютаВзаиморасчетов КАК Валюта
|ИЗ
| РегистрБухгалтерии.Проводки.Остатки(&ТекущийМомент, Счет = ЗНАЧЕНИЕ(ПланСчетов.Управленческий.Покупатели), , Субконто1 = &Контрагент) КАК ПроводкиОстатки
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют.СрезПоследних(&Дата, ) КАК КурсыВалютСрезПоследних
| ПО ПроводкиОстатки.Субконто2.ВалютаВзаиморасчетов = КурсыВалютСрезПоследних.Валюта
|
|УПОРЯДОЧИТЬ ПО
| СуммаЗадолженности УБЫВ
|ИТОГИ
| МАКСИМУМ(СуммаНадоСписать),
| СУММА(СуммаЗадолженности),
| СУММА(СуммаВалютыОстаток)
|ПО
| Контрагент";
Запрос.УстановитьПараметр("Дата", Дата);
Запрос.УстановитьПараметр("ТекущийМомент", МоментВремени());
Запрос.УстановитьПараметр("Контрагент", Контрагент);
Запрос.УстановитьПараметр("СуммаНадоСписать", СуммаВРублях);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаКонтрагент = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаКонтрагент.Следующий() Цикл
Если ВыборкаКонтрагент.СуммаНадоСписать > ВыборкаКонтрагент.СуммаЗадолженности Тогда
Отказ = Истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "По контрагенту " + ВыборкаКонтрагент.Контрагент + " максимальная сумма распределения " + ВыборкаКонтрагент.СуммаЗадолженности +" руб.";
Сообщение.Сообщить();
КонецЕсли;
Если НЕ Отказ Тогда
СуммаНадоСписать = ВыборкаКонтрагент.СуммаНадоСписать;
ВыборкаДетальныеЗаписи = ВыборкаКонтрагент.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
Движение = Движения.Проводки.Добавить();
Движение.СчетДт = ПланыСчетов.Управленческий.Касса;
Движение.СчетКт = ПланыСчетов.Управленческий.Покупатели;
Движение.Период = Дата;
Движение.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Контрагент] = ВыборкаДетальныеЗаписи.Контрагент;
Движение.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Договор] = ВыборкаДетальныеЗаписи.Договор;
Если СуммаНадоСписать >= ВыборкаДетальныеЗаписи.СуммаЗадолженности Тогда
Движение.Сумма = ВыборкаДетальныеЗаписи.СуммаЗадолженности;
Движение.СуммаВалютыКт = ВыборкаДетальныеЗаписи.СуммаВалютыОстаток;
СуммаНадоСписать = СуммаНадоСписать - ВыборкаДетальныеЗаписи.СуммаЗадолженности;
Иначе
Движение.Сумма = СуммаНадоСписать;
Движение.СуммаВалютыКт = СуммаНадоСписать / ВыборкаДетальныеЗаписи.Курс;
СуммаНадоСписать = 0;
КонецЕсли;
Если СуммаНадоСписать = 0 Тогда
Прервать;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
//{{__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
// Данный фрагмент построен конструктором.
// При повторном использовании конструктора, внесенные вручную изменения будут утеряны!!!
//}}__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
КонецПроцедуры
-
Переформулируй свой вопрос, RA. Не пойму, что ты хочешь услышать. Ты привел текст запроса на списание задолженностей, начиная с самой большой. Как здесь можно обойтись одним конструктором?
-
По поводу использования конструктора запросов могу добавить.
В правилах экзамена сказано, что конфигурация должна работать корректно при наличии дублей строк.
Группировка в запросе решает эту проблему, конструктор запросов - нет.
И ещё.
Будет ошибкой делать следующее.
В приходной накладной, если делаете проверку в цикле,
что бы не приходовать услуги на склад.
Что-то типа "Если Номенлатура.Услуга тогда".
Обращение через точку здесь - это запрос в цикле.
За это минус.
По п.1 - это не так, если данные могут быть получены только из документа. Пример - проведение приходной накладной по регистру остатков. Даже если будет несколько строк в документе - ну будет несколько записей в регистре, какие тут проблемы.
А вот по п.2 согласен абсолютно: проверку в цикле "Если Номенлатура.Услуга тогда" однозначно убирать в запрос, т.к. фактически для каждой строки выполняется получение всех реквизитов "номенклатура" текущей строки и по большому счету это аналогично ошибке "запрос в цикле" (Белоусов на своих курсах это так и назвал). Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
-
Подскажите, при попытке получения актуальных билетов (или иных обращениях к ссылкам на форуме) получаю сообщение о невозможности открытия файла (картинка во вложении). Кто и как сейчас это обходит?
Как получить актуальные билеты и прочие вложения форума?
-
Зайди в тему "Актуальные билеты". В самом конце, на последней странице темы, у одного из форумчан есть ответ с вложением.
https://forum.chistov.pro/index.php?topic=2670.1140 (https://forum.chistov.pro/index.php?topic=2670.1140)
-
По поводу использования конструктора запросов могу добавить.
В правилах экзамена сказано, что конфигурация должна работать корректно при наличии дублей строк.
Группировка в запросе решает эту проблему, конструктор запросов - нет.
И ещё.
Будет ошибкой делать следующее.
В приходной накладной, если делаете проверку в цикле,
что бы не приходовать услуги на склад.
Что-то типа "Если Номенлатура.Услуга тогда".
Обращение через точку здесь - это запрос в цикле.
За это минус.
По п.1 - это не так, если данные могут быть получены только из документа. Пример - проведение приходной накладной по регистру остатков. Даже если будет несколько строк в документе - ну будет несколько записей в регистре, какие тут проблемы.
А вот по п.2 согласен абсолютно: проверку в цикле "Если Номенлатура.Услуга тогда" однозначно убирать в запрос, т.к. фактически для каждой строки выполняется получение всех реквизитов "номенклатура" текущей строки и по большому счету это аналогично ошибке "запрос в цикле" (Белоусов на своих курсах это так и назвал). Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
-
Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
Выборка.Номенклатура будет содержать ссылку на элемент справочнику, ГУИД, Уникальный идентификатор, как Вам будет более понятно.
Если вам нужна именно ссылка, например, при записи в регистр, то используйте именно Выборка.Номенклатура.
Но если Вы выводите наименование номенклатуры, например через оператор Сообщить, то передавая параметром Выборка.Номенклатура в оператор Сообщить Вы заставляете систему обращаться к базе данных для получения представления поля, система же не может вывести Ссылку, вот и приходиться обращаться к базе данных для получения представления. А так как это действие выполняется в данном случае в цикле, то и получается запрос в цикле к базе данных, пускай и не явный.
Под "Выборка.НоменклатураПредставление" автор имел в виду запросом из Номенклатуры получить поле Представление (оно будет среди всех полей номенклатуры) и выводить в операторе Сообщить именно его. В данном случае Представление будет содержать Наименование элемента справочника.
-
Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
Выборка.Номенклатура будет содержать ссылку на элемент справочнику, ГУИД, Уникальный идентификатор, как Вам будет более понятно.
Если вам нужна именно ссылка, например, при записи в регистр, то используйте именно Выборка.Номенклатура.
Но если Вы выводите наименование номенклатуры, например через оператор Сообщить, то передавая параметром Выборка.Номенклатура в оператор Сообщить Вы заставляете систему обращаться к базе данных для получения представления поля, система же не может вывести Ссылку, вот и приходиться обращаться к базе данных для получения представления. А так как это действие выполняется в данном случае в цикле, то и получается запрос в цикле к базе данных, пускай и не явный.
Под "Выборка.НоменклатураПредставление" автор имел в виду запросом из Номенклатуры получить поле Представление (оно будет среди всех полей номенклатуры) и выводить в операторе Сообщить именно его. В данном случае Представление будет содержать Наименование элемента справочника.
Так в итоге как нужно? много задач с выборкой, много с представлением, а как нужно точно не ясно))
-
Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
Выборка.Номенклатура будет содержать ссылку на элемент справочнику, ГУИД, Уникальный идентификатор, как Вам будет более понятно.
Если вам нужна именно ссылка, например, при записи в регистр, то используйте именно Выборка.Номенклатура.
Но если Вы выводите наименование номенклатуры, например через оператор Сообщить, то передавая параметром Выборка.Номенклатура в оператор Сообщить Вы заставляете систему обращаться к базе данных для получения представления поля, система же не может вывести Ссылку, вот и приходиться обращаться к базе данных для получения представления. А так как это действие выполняется в данном случае в цикле, то и получается запрос в цикле к базе данных, пускай и не явный.
Под "Выборка.НоменклатураПредставление" автор имел в виду запросом из Номенклатуры получить поле Представление (оно будет среди всех полей номенклатуры) и выводить в операторе Сообщить именно его. В данном случае Представление будет содержать Наименование элемента справочника.
Так в итоге как нужно? много задач с выборкой, много с представлением, а как нужно точно не ясно))
В операторе Сообщить однозначно использовать не ссылку, а представление объекта.
-
Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
Выборка.Номенклатура будет содержать ссылку на элемент справочнику, ГУИД, Уникальный идентификатор, как Вам будет более понятно.
Если вам нужна именно ссылка, например, при записи в регистр, то используйте именно Выборка.Номенклатура.
Но если Вы выводите наименование номенклатуры, например через оператор Сообщить, то передавая параметром Выборка.Номенклатура в оператор Сообщить Вы заставляете систему обращаться к базе данных для получения представления поля, система же не может вывести Ссылку, вот и приходиться обращаться к базе данных для получения представления. А так как это действие выполняется в данном случае в цикле, то и получается запрос в цикле к базе данных, пускай и не явный.
Под "Выборка.НоменклатураПредставление" автор имел в виду запросом из Номенклатуры получить поле Представление (оно будет среди всех полей номенклатуры) и выводить в операторе Сообщить именно его. В данном случае Представление будет содержать Наименование элемента справочника.
Так в итоге как нужно? много задач с выборкой, много с представлением, а как нужно точно не ясно))
В операторе Сообщить однозначно использовать не ссылку, а представление объекта.
Спасибо большое за помощь, вижу многим здесь помогаете))
-
Аналогично при выводе ошибки, например Сообщить("по номенклатуре " + Выборка.Номенклатура " не хватает остатка"); нужно выводить НоменклатураПредставление, полученное в запросе, иначе при выводе в сообщении Выборка.Номенклатура - это неявный запрос к базе данных в цикле.
Что значит представление?? Привыкла обращаться выборка.Номенклатура, теперь запуталась
Выборка.Номенклатура будет содержать ссылку на элемент справочнику, ГУИД, Уникальный идентификатор, как Вам будет более понятно.
Если вам нужна именно ссылка, например, при записи в регистр, то используйте именно Выборка.Номенклатура.
Но если Вы выводите наименование номенклатуры, например через оператор Сообщить, то передавая параметром Выборка.Номенклатура в оператор Сообщить Вы заставляете систему обращаться к базе данных для получения представления поля, система же не может вывести Ссылку, вот и приходиться обращаться к базе данных для получения представления. А так как это действие выполняется в данном случае в цикле, то и получается запрос в цикле к базе данных, пускай и не явный.
Под "Выборка.НоменклатураПредставление" автор имел в виду запросом из Номенклатуры получить поле Представление (оно будет среди всех полей номенклатуры) и выводить в операторе Сообщить именно его. В данном случае Представление будет содержать Наименование элемента справочника.
Так в итоге как нужно? много задач с выборкой, много с представлением, а как нужно точно не ясно))
В операторе Сообщить однозначно использовать не ссылку, а представление объекта.
хотела Вас попросить посмотреть билет, только ОУ, так как по нему у меня и моих коллег есть разногласия..кто то говорит нужно константу создавать для хранения даты самого раннего документа, требующего допроведения. Документ сравнивает свою дату с датой, сохранённой константе, и, если его дата более ранняя (или если константа вообще не содержит даты), сохранит в константе свою дату. Точнее не дату, а моментВремени. А так как константы не могут иметь такой тип, поэтому, определяем не самый первый документ, а самую раннюю дату.
кто то говорит надо в общем модуле рассчитывать себестоимость, а кто то в расходной. И меня все путают, вот лучше у Вас узнаю
-
хотела Вас попросить посмотреть билет, только ОУ, так как по нему у меня и моих коллег есть разногласия..кто то говорит нужно константу создавать для хранения даты самого раннего документа, требующего допроведения. Документ сравнивает свою дату с датой, сохранённой константе, и, если его дата более ранняя (или если константа вообще не содержит даты), сохранит в константе свою дату. Точнее не дату, а моментВремени. А так как константы не могут иметь такой тип, поэтому, определяем не самый первый документ, а самую раннюю дату.
кто то говорит надо в общем модуле рассчитывать себестоимость, а кто то в расходной. И меня все путают, вот лучше у Вас узнаю
Давайте будем стараться вопросы задавать в соответствующих тематических ветках. Эта ветка касается расхождений в билетах на экзамене от ожидаемых и методов их решения. Иначе тему превратим в мусорку. Продублируйте Ваш вопрос, например, в обсуждении первого билета или другой ветке общих вопросов. Я посмотрю.
-
хотела Вас попросить посмотреть билет, только ОУ, так как по нему у меня и моих коллег есть разногласия..кто то говорит нужно константу создавать для хранения даты самого раннего документа, требующего допроведения. Документ сравнивает свою дату с датой, сохранённой константе, и, если его дата более ранняя (или если константа вообще не содержит даты), сохранит в константе свою дату. Точнее не дату, а моментВремени. А так как константы не могут иметь такой тип, поэтому, определяем не самый первый документ, а самую раннюю дату.
кто то говорит надо в общем модуле рассчитывать себестоимость, а кто то в расходной. И меня все путают, вот лучше у Вас узнаю
Давайте будем стараться вопросы задавать в соответствующих тематических ветках. Эта ветка касается расхождений в билетах на экзамене от ожидаемых и методов их решения. Иначе тему превратим в мусорку. Продублируйте Ваш вопрос, например, в обсуждении первого билета или другой ветке общих вопросов. Я посмотрю.
Хорошо