Форум Чистова. Подготовка к экзаменам 1С
Аттестация "1С:Специалист" => Аттестация "1С:Специалист по платформе 1С:Предприятие 8.3 и 8.2" => Тема начата: Jones от Август 12, 2015, 04:44:54 pm
-
Сделал 6 билет, правда без УФ
Надо сказать вроде все просто, но работы здесь много и без управляемых форм. Как люди все это на экзамене успевают – не знаю. Умные наверное ))
1) По ПР задача 3.40 с изменениями
ОплатыПассажиров храню в оборотном регистре (не грех?)
Автомобиль – измерение. Вроде так правильно, если водители могут ими меняться.
График и Автомобиль поместил в РР и рег.Графики.
В РегистреРасчета связал их с Графиком
Размер гарантированного Оклада задаю прямо в ТЧ. Сделал его в ОН (с периодом действия), чтобы определять ФактДни и записывать в ресурс ОтработаноДней, нужный для расчета Отпуска.
2) По БУ задача 2.16
В моем решении Количество и Сумма на счете Товары хранятся в разрезе Ном, Складов и Партий. Но правильно ли это? Может имеется ввиду, что надо Стоимость хранить (и списывать) только в разрезе Ном+Партия?
Или я придумываю? Ведь в задании не сказано считать Себестоимость в среднем по всем складам.
В общем, на счТовары 3 субконто: Ном, Склад, Партия
Ресурсы Сумма, Количество (небаланс, Количественный)
Отчет простой.
3) В ОперУчете задача 1.13. Обеспечил что деталь не может относиться к разным стеллажам через регистр сведений. Деталь – Измерение, Ресурсы: Стеллаж и КоличествоДеталиВСтеллаже
Использовал новую методику, благо себестоимость учитывать не надо.
Посмотрите, кому не лень, верно ли я новую методику использую?
Сначала Движения БлокироватьДляИзменения, затем списал Детали, записал движения, затем на ГраницуВключая посмотрел, не возникло ли минусов.
Отчетик простецкий: получаем остатки деталей и для каждой детали выводим Стеллаж, к которому она относится.
УФ задача 5.04. Делать не стал. Буду благодарен, если кто-нибудь доделает.
-
ОУ по коду выглядит нормально.
В БУ выскакивает ошибка при перепроведении расходной накладной №1. Похоже, что код для ОУ был написан после БУ. :)
2) По БУ задача 2.16
В моем решении Количество и Сумма на счете Товары хранятся в разрезе Ном, Складов и Партий. Но правильно ли это? Может имеется ввиду, что надо Стоимость хранить (и списывать) только в разрезе Ном+Партия?
Или я придумываю? Ведь в задании не сказано считать Себестоимость в среднем по всем складам.
В общем, на счТовары 3 субконто: Ном, Склад, Партия
Ресурсы Сумма, Количество (небаланс, Количественный)
Отчет простой.
У меня в этой задаче склад без суммового учета. Если суммовой по складам оставить, тогда невозможно соблюдение условия списания с/с по партиям - не сказано же, что партии внутри склада. Я думаю так. :)
-
Похоже, что код для ОУ был написан после БУ. :)
Так и есть. Голова уже кругом идет. Все в кучу, толком и не протестил :)
не сказано же, что партии внутри склада
Ага, вот это я и подозревал )). Спасибо за подсказку alex1248. Свое решение выложишь? Хотел бы перенять опыт.
-
Заметил, что у меня Оклад не вытесняется Отпуском. Надо исправить, а то ОтработаноЧасов будет неверным при наличии Отпуска.
-
... Голова уже кругом идет ...
Я перерыв сделал на 2 дня, надо за них разобраться с УФ, А то у меня этот раздел почти на нуле (кроме того, я у всех документов отображение регистров настраиваю, так тестить удобней).
... Свое решение выложишь? Хотел бы перенять опыт.
Хаха, про опыт очень смешно. :D
В этом БУ у меня еще не было ни блокировок, ни Операции. Но прикрепляю, чего уж там скрывать. Хотя, надеюсь, через недельку будет лучшего качества и в комплекте. :D
А вот эта задача очень простая, приход, расход по партиям, никаких нюансов.
Кстати, по поводу опыта, вот тут очень занимательное чтиво
http://forum.chistov.pro/index.php?topic=993.0 ,
если с самого начала читать. Как раз все нюансы с самого начала сдачи на 8.2 обсуждаются. Подозреваю, что и по поводу пресловутых "данных за разные расчетные периоды" инфу найти можно. :)
-
В СПР есть условие "Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег". Не будет ли ошибкой в данной оплате в настройках указывать "Использует период действия" - Истина?
Есть вид расчета "Невыход", может по аналогии создать вид расчета что-то типа "Работа", где и будут храниться отработанные дни, необходимые для расчета отпуска? А фиксированная сумма денег пусть будет без периода действия. Что Вы скажете?
-
В СПР есть условие "Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег". Не будет ли ошибкой в данной оплате в настройках указывать "Использует период действия" - Истина?
Есть вид расчета "Невыход", может по аналогии создать вид расчета что-то типа "Работа", где и будут храниться отработанные дни, необходимые для расчета отпуска? А фиксированная сумма денег пусть будет без периода действия. Что Вы скажете?
На сколько я понял, если ФиксОклад занести в ОН (начисления с ПериодомДействия), то это надо как-то обосновать, ведь для расчета ему ПериодДействия не нужен.
Вариант добавить ВР Работа мне кажется возможным, но наверное надо, чтобы он записывался автоматически, чтобы пользователю не приходилось заносить в ТЧ два ВР: и ФиксОклад и Работу
-
// сторнирование не нужно
Если не секрет, когда оно нужно, а когда нет?
На сколько мне известно, сторнирование необходимо делать тогда, когда в условии есть формулировка
"Следует учесть, что данные о командировке могут вводиться в систему задним числом"
-
Балин! Сделал первую часть задания через подчиненные справочники, а в последней (где управляемые формы) выясняется что реквизит табличной части в расходной накладной не может быть составного вида, иначе к нему свою модифицированную форму выбора не привяжешь.
-
Переделал на "Иерархия элементов". Теперь и Стеллажи и комплектующие в одном справочнике.
-
Переделал на "Иерархия элементов". Теперь и Стеллажи и комплектующие в одном справочнике.
А чего не прикрепил то?
-
21 августа сдавал экзамен, попалась эта задача по СПР.
Делал так:
1) в РС график не нужен, делал только измерение Автомобиль, а для отпуска завел отдельно ресурс "ЗначениеПятидневка"
2) в РР Автомобиль сделал тоже измерение, за что получил вопрос зачем. Я конечно пояснил, что автомобилями могут менятся. Либо экзаменатор меня проверял осознано ли я сделал, либо по задаче было не однозначно понятно.
Одно дело работать в разных подразделениях и совмещать работу, а другое дело менять машины, одновременно же не будешь работать на двух машинах. В общем не сказал что ошибка.
3) Фикс сумму сделал с "использовать период действия" за что получил негативный вопрос "ЗАЧЕМ"? Ясно же написано что "НЕ ЗАВИСИМО ОТ ОТРАБОТАННОГО ВРЕМЕНИ".
На самом деле формулировка задачи на экзамене немного изменена(я не заметил, делал как готовился), звучит так "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во РАБОЧИХ дней за пред. 3 месяца".
Не путать с отработанными днями. Короче дни теперь нужно собирать по-другому не по базе, а по графику, поэтому "использовать период действия" здесь не нужно.
4) ОплатыПассажиров храню в оборотном регистре (не грех?) = так и делал, не грех.
5) Еще в этой задаче добавился один отчет "Перерасчет зарплаты", которого нет в файле "Актуальные билеты на экзамене..."
В остальном по этой задаче замечаний не было.
-
поясните:
если нужно "...Еще в этой задаче добавился один отчет "Перерасчет зарплаты"..."
тогда как быть с этим ... ОплатыПассажиров храню в оборотном регистре (не грех?) = так и делал...
Я догадываюсь что в отчет должны попадать данные которые нужно пересчитать. Если вводить оплаты отдельными документами и писать в РН отработанное время которое уже учитывать при проведении док.НЗ, тогда этот отчет всегда будет пустой.
либо же добавить Начисление ОплатыПассажиров писать туда сумму и уже док.НЗ брать базу. и только тогда появятся данные в отчете.
-
3) Фикс сумму сделал с "использовать период действия" за что получил негативный вопрос "ЗАЧЕМ"? ...
звучит так "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во РАБОЧИХ дней за пред. 3 месяца"...
А отпуск был, или еще какой-нибудь ВР, предполагающий расчет в зависимости от количества отработанных дней?
-
3) Фикс сумму сделал с "использовать период действия" за что получил негативный вопрос "ЗАЧЕМ"? ...
звучит так "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во РАБОЧИХ дней за пред. 3 месяца"...
А отпуск был, или еще какой-нибудь ВР, предполагающий расчет в зависимости от количества отработанных дней?
Если отпуск тогда нужен? вытеснить его кладом по периоду действия да?
-
А отпуск был, или еще какой-нибудь ВР, предполагающий расчет в зависимости от количества отработанных дней?
Отпуск был, но с поправкой на расчет средней ставки, см. выше. В остальном содержание задачи осталось прежним.
Больше ни каких ВР, предполагающий расчет в зависимости от количества отработанных дней, НЕ БЫЛО.
По поводу нового отчета "Перерасчет зарплаты", я его не делал (уже не было времени), комментарий по этому отчету дать не могу.
Другой отчет по ВР был и я его сделал, видимо его засчитали.
-
Задачу по ПР 06 билета нахожу неоднозначной, плюс не до конца расшифровал код формулировки задачи, поэтому не знаю, как точно должно выглядеть решение «правильное» с точки зрения экзаменаторов.
Посмотрел решение ПР 6 билета от S_A_E (http://forum.chistov.pro/index.php?topic=2670.msg41577#msg41577) и оно мне понравилось.
S_A_E добавил в рег Графики ресурс ДниПятидневки, измерения График у него в рег.свед.нет, как и самого справочника Графики, думаю это правильно.
Переделал по методике S_A_E, теперь хорошо бы все это вспомнить, если задача попадется.
В задаче Оклад не зависит от фактически отработанного времени, поэтому его, по идее, надо помещять в ДН. Но для расчета Отпуска необходимо получать ОтработанныеДни за базовый период, поэтому Оклад сделал в ОН и ОтработанныеДни заполняю из ДнейФакт Оклада.
Как выше сообщал Евгений, здесь экзаменатор может придраться, поэтому надо быть готовым объяснить, зачем Оклад в ОН, а при дистанционной сдаче надо не забыть отметить это в пояснении.
С фразой «Один календарный месяц в году» решил ничего не городить т.к. это долго (воображение рисует всякие проверки на количество уже отгулянного в этом году отпуска).
В задании порадовало, что «В одном документе могут быть данные только за текущий расчетный период» и довольно простой отчет.
Поделюсь опытом, может кому пригодится.
При разработке допустил ошибку, которой на экзамене делать нельзя: не установил связь с графиком для измерения Автомобиль РР ОН, затем заполнил График в предприятии, создал док Начисление и понял, что ДниФакт в таблицу ДанныеГрафика попадают, но без отбора по Автомобилю (по всем Автомобилям). Тогда я установил связь с графиком для измерения Автомобиль и ДниФакт вообще перестали попадать в ДанныеГрафика.
Дальше, чтобы я ни делал, ДниФакт оставались не заполненными:
заново заполнял рег Графики, создавал новый документ, выгружал-загружал конфигурацию, загружал конфигурацию в новую БД, полностью выходил из базы, пересчитывал итоги – все бесполезно.
Зато стоило снова отключить связь с графиком, как ДанныеГрафика заполнялись, но проблема в том, что в ДниФакт попадали графики обоих Автомобилей, присутствующих в регистре Графики.
Минут через 5 для себя решил, что на экзамене бросил бы это, просто удалил бы одну машину из регистра и все, но сейчас надо было найти решение и в итоге мне это удалось.
Пришлось удалить измерения Автомобиль из РР ОН и из рег свед Графики, затем создать новые, применить, заполнить рег Графики, провести документ и.. Вуаля! Связь с графиком заработала корректно.
Итак: на борьбу с недокументированным глюком платформы потратил почти ПОЛЧАСА, что на экзамене недопустимо. Быстрое решение: удалить связку измерений (Автомобиль- Автомобиль) и создать ее заново.
-
В задаче Оклад не зависит от фактически отработанного времени, поэтому его, по идее, надо помещять в ДН. Но для расчета Отпуска необходимо получать ОтработанныеДни за базовый период, поэтому Оклад сделал в ОН и ОтработанныеДни заполняю из ДнейФакт Оклада.
Это противоречит фразе из условия: "...осуществляется ежемесячно с использованием метода отклонений." Напрашивается отклонение от фиксированной суммы. А фраза "не зависит от отработанного времени" можно растолковать так, что один работал по такому то графику 150 часов а другой по другому графику 180 часов, но получат фиксированную сумму они одинаковую.
В этом случае, правда, в ситуации со сменой машины в течение расчетного периода, как и с отпуском лучше не углубляться :)
-
S_A_E добавил в рег Графики ресурс ДниПятидневки, измерения График у него в рег.свед.нет, как и самого справочника Графики, думаю это правильно.
Еещ возможный вариант - я делал измерение (надо было реквизит) Автомобиль и реквизит График. Реквизит График составного типа СправочникСсылка.Автомобили + Перечисление.СтандартныеГрафики.Пятидневка. Гончаров спрашивал, зачем и Автомобиль и График, но моё указание на то, что в графике для отпуска вместо автомобиля записывается пятидневка его удовлетворило (это так же и к тому, что своеобразные решения принимаются, если они логичны и обосновываются).
В задаче Оклад не зависит от фактически отработанного времени, поэтому его, по идее, надо помещять в ДН. Но для расчета Отпуска необходимо получать ОтработанныеДни за базовый период, поэтому Оклад сделал в ОН и ОтработанныеДни заполняю из ДнейФакт Оклада.
Как выше сообщал Евгений, здесь экзаменатор может придраться, поэтому надо быть готовым объяснить, зачем Оклад в ОН, а при дистанционной сдаче надо не забыть отметить это в пояснении.
У меня никаких проблем с ОН не возникло. :)
С фразой «Один календарный месяц в году» решил ничего не городить т.к. это долго (воображение рисует всякие проверки на количество уже отгулянного в этом году отпуска).
Я понял (и реализовал) эту фразу несколько иначе. Календарный месяц - это один месяц с 1-го по последнее число. Поэтому для отпуска НПД я приводил к началу месяца, КПД - к концу месяца (было принято).
Поделюсь опытом, может кому пригодится.
При разработке допустил ошибку, которой на экзамене делать нельзя: не установил связь с графиком для измерения Автомобиль РР ОН...
Тут есть еще одна ошибка. Автомобиль должен быть реквизитом, аргумент - один водитель не может одновременно ездить на разных автомобилях (слова Гончарова).
-
поясните:
если нужно "...Еще в этой задаче добавился один отчет "Перерасчет зарплаты"..."
тогда как быть с этим ... ОплатыПассажиров храню в оборотном регистре (не грех?) = так и делал...
Я догадываюсь что в отчет должны попадать данные которые нужно пересчитать. Если вводить оплаты отдельными документами и писать в РН отработанное время которое уже учитывать при проведении док.НЗ, тогда этот отчет всегда будет пустой.
либо же добавить Начисление ОплатыПассажиров писать туда сумму и уже док.НЗ брать базу. и только тогда появятся данные в отчете.
В решении Agamest-а вместо регистра "ОплатыПассажиров" в табличной части документа "НачислениеЗарплаты" используется реквизит "СуммаОплатПассажировЗаПрошлыйМесяц", куда пользователи вводят значение руками. Соответственно меняется эта сумма -> перепроводится весь документ "НачислениеЗарплаты" и перерасчеты отрабатывают корректно.
-
Фикс сумму сделал с "использовать период действия" за что получил негативный вопрос "ЗАЧЕМ"? Ясно же написано что "НЕ ЗАВИСИМО ОТ ОТРАБОТАННОГО ВРЕМЕНИ".
На самом деле формулировка задачи на экзамене немного изменена(я не заметил, делал как готовился), звучит так "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во РАБОЧИХ дней за пред. 3 месяца".
Не путать с отработанными днями. Короче дни теперь нужно собирать по-другому не по базе, а по графику, поэтому "использовать период действия" здесь не нужно.
Отпуска считаются по пятидневке. Ставку для отпуска считаем по количеству РАБОЧИХ, а не отработанных дней. Где тогда используем графики работы для автомобилей?
Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно.
-
Покритикуйте, пожалуйста, мое решение.
1. Стеллажи сделаны на иерархии элементов.
2. Оклад и Надбавки не зависят от периода действия, в расчете отпуска берется количество РАБОЧИХ дней по базе, а не отработанных по виду расчета "оклад".
-
ОУ.
Очень сомнительна правльность выбора хранения данных в виде иерархии элементов.
В обработке проведения РН выгрузка в таблицу значений без необходимости.
Если в результате проверки новых остатков ушли в минус, можно сразу завершать обработку проведения, не приступая к формированию движений БУ.
Для блокировки используется запись конкретного набора записей, а не Движения.Записать(). Может быть, в этом ничего страшного и нет.
БУ.
При установке управляемой блокировки одновременное использование источника данных и установить значение.
Перед установкой блокировки код Движения.РегистрБухгалтерии1.БлокироватьДляИзменения = ИСТИНА;
Движения.РегистрБухгалтерии1.Очистить();
Движения.РегистрБухгалтерии1.Записать(); выполнятся в любом случае, а не только при оперативном проведении.
Так же интересует обоснованность выбора порядка субконто на счете Товары: Номенклатура, Склады, Партии. Почему не Номенклатура, Партии, Склады?
В запросах по регистру бухгалтерии при левом соединении в параметрах виртуальной таблицы нет условия на номенклатуру.
-
При установке управляемой блокировки одновременное использование источника данных и установить значение.
Если не ошибаюсь, вы уже где-то писали об этом и цитату из книжки приводили?
Так вот, даже в той цитате был еще такой текст: "для одного поля регистра". А здесь ситуация иная, так что всё норм.
Так же интересует обоснованность выбора порядка субконто на счете Товары: Номенклатура, Склады, Партии. Почему не Номенклатура, Партии, Склады?
Разве порядок субконто в плане счетов имеет значение?
-
Так вот, даже в той цитате был еще такой текст: "для одного поля регистра"
Точно, спасибо, теперь разобрался. :)
Разве порядок субконто в плане счетов имеет значение?
Профессиональная разработка, том 1, стр 633. Принятие решений. Пример конкретно этого набора субконто: Номенклатура, партии, склады.
-
Разве порядок субконто в плане счетов имеет значение?
Профессиональная разработка, том 1, стр 633. Принятие решений. Пример конкретно этого набора субконто: Номенклатура, партии, склады.
Ага, значит, имеет.
Но в этой задаче я всё же Склады поставил бы раньше партий - при списании проверка в первую очередь идет по ним, и отчет строится только по складам.
-
Покритикуйте, пожалуйста, мое решение.
Меня еще смущает вот какой момент.
Смотрим внимательно запрос.
ВЫБРАТЬ
ЕСТЬNULL(СпрКомплектующие.Ссылка, РасходнаяНакладнаяСписокНоменклатуры.Номенклатура) КАК Номенклатура,
СУММА(ЕСТЬNULL(СпрКомплектующие.КоличествоВСтеллаже, 1) * РасходнаяНакладнаяСписокНоменклатуры.Количество) КАК Количество
ПОМЕСТИТЬ ДокТЧ
ИЗ
Документ.РасходнаяНакладная.СписокНоменклатуры КАК РасходнаяНакладнаяСписокНоменклатуры
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК СпрКомплектующие
ПО РасходнаяНакладнаяСписокНоменклатуры.Номенклатура = СпрКомплектующие.Родитель
ГДЕ
РасходнаяНакладнаяСписокНоменклатуры.Ссылка = &Ссылка
СГРУППИРОВАТЬ ПО
ЕСТЬNULL(СпрКомплектующие.Ссылка, РасходнаяНакладнаяСписокНоменклатуры.Номенклатура)
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ДокТЧ.Номенклатура КАК Номенклатура,
ДокТЧ.Количество КАК КоличествоВДокументе,
РегистрБухгалтерии1СуммаПартии.Субконто3 КАК Партия,
ЕСТЬNULL(РегистрБухгалтерии1Остатки.КоличествоОстатокДт, 0) КАК КоличествоОстатокДт,
ЕСТЬNULL(РегистрБухгалтерии1СуммаПартии.СуммаОстатокДт, 0) КАК СуммаОстатокПартии,
ЕСТЬNULL(РегистрБухгалтерии1СуммаПартии.КоличествоОстатокДт, 0) КАК КоличествоПартии
ИЗ
ДокТЧ КАК ДокТЧ
ЛЕВОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.РегистрБухгалтерии1.Остатки(&МоментВремени, Счет = ЗНАЧЕНИЕ(ПланСЧетов.Управленческий.ТОвары), &МассивТиповСубконто, Субконто2 = &НашСклад) КАК РегистрБухгалтерии1Остатки
ПО ДокТЧ.Номенклатура = РегистрБухгалтерии1Остатки.Субконто1
ЛЕВОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.РегистрБухгалтерии1.Остатки(&МоментВремени, Счет = ЗНАЧЕНИЕ(ПланСЧетов.Управленческий.ТОвары), , ) КАК РегистрБухгалтерии1СуммаПартии
ПО ДокТЧ.Номенклатура = РегистрБухгалтерии1СуммаПартии.Субконто1
УПОРЯДОЧИТЬ ПО
РегистрБухгалтерии1СуммаПартии.Субконто3.МоментВремени.
.
.
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
// Вставить обработку выборки ВыборкаДетальныеЗаписи
ДвижениеБУ = Движения.РегистрБухгалтерии1.Добавить();
ДвижениеБУ.СчетДт = ПланыСчетов.Управленческий.ПрибылиУбытки;
ДвижениеБУ.СчетКт = ПланыСчетов.Управленческий.Товары;
ДвижениеБУ.Период = Дата;
ДвижениеБУ.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = ВыборкаДетальныеЗаписи.Номенклатура;
ДвижениеБУ.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Склады] = Склад;
ДвижениеБУ.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Партия] = ВыборкаДетальныеЗаписи.Партия;
ДвижениеБУ.КоличествоКТ = МИН(ВыборкаДетальныеЗаписи.КоличествоПартии,ТекКоличество);
Если ВыборкаДетальныеЗаписи.КоличествоПартии = ДвижениеБУ.КоличествоКТ Тогда
ДвижениеБУ.Сумма = ВыборкаДетальныеЗаписи.СуммаОстатокПартии;
иначе
ДвижениеБУ.Сумма = ВыборкаДетальныеЗаписи.СуммаОстатокПартии * ДвижениеБУ.КоличествоКТ/ВыборкаДетальныеЗаписи.КоличествоПартии;
КонецЕсли;
ТекКоличество = ТекКоличество - ДвижениеБУ.КоличествоКТ;
Если ТекКоличество = 0 Тогда
Прервать;
КонецЕсли;
КонецЦикла;
Допустим, у нас есть несколько поступлений позиции номенклатуры на разные склады. При списании может случиться так, что товар будет списан со склада по партии, которая записывала на другой склад. Таким образом, при некотором наборе остатков, при списании не будет нормально закрываться количество по складу.
-
alex1248,
в Вашем решении http://forum.chistov.pro/index.php?action=dlattach;topic=3670.0;attach=1122 (http://forum.chistov.pro/index.php?action=dlattach;topic=3670.0;attach=1122), похоже, возможны отрицательные остатки по сумме.
-
После некоторых изысканий, пришел к выводу, что задачу БУ нужно решать следующим образом: делать партионное списание два раза. Первый раз таблицу документа соединяем с остатками по регистру бухгалтерии по всем субконто, фильтр по субконто-складу. Списываем по партиям только количество.
Потом делаем еще один запрос, таблицу документа соединяем с остатками без фильтра по складу, сгруппированными по Номенклатура, Партия. И снова делаем партионное списание, но в проводку пишем только сумму.
Пример прилагаю. Прошу жестоко критиковать.
-
alex1248,
в Вашем решении http://forum.chistov.pro/index.php?action=dlattach;topic=3670.0;attach=1122 (http://forum.chistov.pro/index.php?action=dlattach;topic=3670.0;attach=1122), похоже, возможны отрицательные остатки по сумме.
Не увидел, каким образом это возможно, если сумма определяется с учетом суммы остатка по данной партии, а списываемое количество меньше или равно количества остатка по партии (Списать = МИН (ОстСписать, ВыбДетали.КоличествоОстПар); ).
Хотя, выложенный вариант я делал в самом начале подготовки, т.е. когда по сути знакомился с синтаксисом и очень поверхностно вникал в суть задач, в то время не были исключены довольно существенные ошибки. Но сверил с последним вариантом, вроде бы довольно схоже, в общем, не увидел проблемы.
На всякий случай, вот последний вариант (однако, и он в целом может быть не образцовым :) ).
-
Не увидел, каким образом это возможно
Я ошибся, действительно все закрывается. Разобрался с кодом, до меня "дошло" :) Спасибо!
-
Всем привет!
В чем заключается разница между:
а. признак учета субконто "суммовой" у склада
б. признак учета субконто "только обороты" у склада
-
Всем привет!
В чем заключается разница между:
а. признак учета субконто "суммовой" у склада
б. признак учета субконто "только обороты" у склада
Во втором случае по складу не хранятся остатки ни по какому ресурсу.
А если сброшен признак учета субконто суммовой в субконто Склад, то по складу не будет храниться остаток суммы, но остаток количества будет храниться.
-
Всем привет!
В чем заключается разница между:
а. признак учета субконто "суммовой" у склада
б. признак учета субконто "только обороты" у склада
Во втором случае по складу не хранятся остатки ни по какому ресурсу.
А если сброшен признак учета субконто суммовой в субконто Склад, то по складу не будет храниться остаток суммы, но остаток количества будет храниться.
Спасибо.
-
Покритикуйте, пожалуйста, мое решение.
1. Стеллажи сделаны на иерархии элементов.
2. Оклад и Надбавки не зависят от периода действия, в расчете отпуска берется количество РАБОЧИХ дней по базе, а не отработанных по виду расчета "оклад".
Подскажи, пожалуйста, как ты передаешь параметры для справочника "Номенклатура"?
-
В некоторых решениях Склад в Приходной находится в шапку документа, а должен быть в ТЧ.
-
Ребят, а почему вы партии списываете в разрезе всех складов, а не склада выбранного в шапке реализации??? Неверно у вас....ни у одного нет правильного решения.
-
Ребят, а почему вы партии списываете в разрезе всех складов, а не склада выбранного в шапке реализации??? Неверно у вас....ни у одного нет правильного решения.
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
-
Ребят, а почему вы партии списываете в разрезе всех складов, а не склада выбранного в шапке реализации??? Неверно у вас....ни у одного нет правильного решения.
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
А тебя не пугает что у тебя остатки в 0 не сведутся никогда и это -2 балла к твоей сдаче в декабре.
-
Ребят, а почему вы партии списываете в разрезе всех складов, а не склада выбранного в шапке реализации??? Неверно у вас....ни у одного нет правильного решения.
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
А тебя не пугает что у тебя остатки в 0 не сведутся никогда и это -2 балла к твоей сдаче в декабре.
Нет, потому что мы отключаем учет остатков на складах с помощью вида* учета субконто. Таким образом, все отлично закрывается. На эту тему есть переписка чуть выше.
* с помощью признака учета субконто, опечатка :)
-
Ребят, а почему вы партии списываете в разрезе всех складов, а не склада выбранного в шапке реализации??? Неверно у вас....ни у одного нет правильного решения.
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
А тебя не пугает что у тебя остатки в 0 не сведутся никогда и это -2 балла к твоей сдаче в декабре.
Нет, потому что мы отключаем учет остатков на складах с помощью вида* учета субконто. Таким образом, все отлично закрывается. На эту тему есть переписка чуть выше.
* с помощью признака учета субконто, опечатка :)
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений. Выходит тогда что нужно партионно списывать только в разрезе склада шапки.
-
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений.
У меня ошибка, правильно у alex1248.
-
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений.
У меня ошибка, правильно у alex1248.
Я уже проверил решения каждого в этой Теме. Нет здесь правильного. А с alex1248 мы только что переговорили и он тоже понял что некорректно у него решение(Тоже в 0 не сведется никогда)
-
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений.
У меня ошибка, правильно у alex1248.
Я уже проверил решения каждого в этой Теме. Нет здесь правильного. А с alex1248 мы только что переговорили и он тоже понял что некорректно у него решение(Тоже в 0 не сведется никогда)
Очень странно, я его решение крутил часа полтора. Я вводил туда данные во всех возможных комбинациях, все проверял через консоль запросов. Таблица итогов закрывалась. При этом, когда я смотрел код, я видел, что не будет здесь закрываться. Потом разобрался. Скачаю сейчас твое, посмотрю что там.
-
Очень странно, я его решение крутил часа полтора. Я вводил туда данные во всех возможных комбинациях, все проверял через консоль запросов. Таблица итогов закрывалась. При этом, когда я смотрел код, я видел, что не будет здесь закрываться. Потом разобрался. Скачаю сейчас твое, посмотрю что там.
На самом деле, если смотреть отдельно по складу, и отдельно по партиям, закрывается. В том виде, какой отчет требуется, всё норм. А вот если посмотреть сам регистр, то по комбинации (партия,склад) идут расхождения, что впрочем, логично, т.к. мы по складу приходуем одни партии, а списываем другие.
Впрочем, уже есть идея - создать 2 ресурса с количеством, с разными признаками учета, думаю, что-то из этого получить можно будет.
Или как у Романа. Но на мой взгляд, всё же формулировка задачи требует списывать партии независимо от склада, поэтому попробую поработать с доп ресурсом.
-
Очень странно, я его решение крутил часа полтора. Я вводил туда данные во всех возможных комбинациях, все проверял через консоль запросов. Таблица итогов закрывалась. При этом, когда я смотрел код, я видел, что не будет здесь закрываться. Потом разобрался. Скачаю сейчас твое, посмотрю что там.
На самом деле, если смотреть отдельно по складу, и отдельно по партиям, закрывается. В том виде, какой отчет требуется, всё норм. А вот если посмотреть сам регистр, то по комбинации (партия,склад) идут расхождения, что впрочем, логично, т.к. мы по складу приходуем одни партии, а списываем другие.
Впрочем, уже есть идея - создать 2 ресурса с количеством, с разными признаками учета, думаю, что-то из этого получить можно будет.
Или как у Романа. Но на мой взгляд, всё же формулировка задачи требует списывать партии независимо от склада, поэтому попробую поработать с доп ресурсом.
В таком случае, предгалаю решать на двух регистрах бухгалтерии и двух планах счетов.
Не стоит этого делать Шкипер).
-
СПР сделал все условия. Возможно усложнил.
ОН: Оклад, Отпуск имеет ПД И Базу от оклада и надбавки, вытесняет отпуск.
ДН: Надбавка без ПД и базы.
Проверка чтобы интервалы из ТЧ не выходили за пределы месяца.
Всё считается, все пункты условия выполнены. но набивал почти 2 час без отрыва и ошибок.
ОУ 4 проверки при записи в РС комплектация.
в прихНакл приходую только то, что отсутствует в РС Комплектация как стеллаж.
Расходная накладная: через комплектацию разворачиваю стеллажи. Новая методика.
БУ Моного времени ушло чтобы склеить с ОУ. точнее додуматься как не выйти за рамки логики.
Счет Товары количественный, Субконто Номенклатура, Партия и Склад несуммовой.
УФ
-
СПР сделал все условия. Возможно усложнил.
ОН: Оклад, Отпуск имеет ПД И Базу от оклада и надбавки, вытесняет отпуск.
ДН: Надбавка без ПД и базы.
Проверка чтобы интервалы из ТЧ не выходили за пределы месяца.
Всё считается, все пункты условия выполнены. но набивал почти 2 час без отрыва и ошибок.
ОУ 4 проверки при записи в РС комплектация.
в прихНакл приходую только то, что отсутствует в РС Комплектация как стеллаж.
Расходная накладная: через комплектацию разворачиваю стеллажи. Новая методика.
БУ Моного времени ушло чтобы склеить с ОУ. точнее додуматься как не выйти за рамки логики.
Счет Товары количественный, Субконто Номенклатура, Партия и Склад несуммовой.
УФ
Ошибка в БУ. Ругистр бухгалтерии не схлопывается в 0, сразу -2 балла от 5. Читать ветку надо.
-
Ошибка в БУ. Ругистр бухгалтерии не схлопывается в 0, сразу -2 балла от 5. Читать ветку надо.
Ветку читал. Честно не понял, где у кого что не списывается.
Посмотрел твое решение. Разницы не заметил, только у тебя одним запросом в расхНакладной, а у меня в два захода, сначала остатки смотрю, в вторым уже выбираю партии.
Не сходится сумма или количество в ноль? на каком субконто?
-
Ошибка в БУ. Ругистр бухгалтерии не схлопывается в 0, сразу -2 балла от 5. Читать ветку надо.
Ветку читал. Честно не понял, где у кого что не списывается.
Посмотрел твое решение. Разницы не заметил, только у тебя одним запросом в расхНакладной, а у меня в два захода, сначала остатки смотрю, в вторым уже выбираю партии.
Не сходится сумма или количество в ноль? на каком субконто?
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений. Выходит тогда что нужно партионно списывать только в разрезе склада шапки или делать два ресурса.....я не стал заморачиваться и усложнять себе задачу и сделал списание партий в разрезе склада.
-
Quantum81 чтобы увидеть ошибку тебе нужно для своей приходной накладной 1 указать склад "Транзитный" - перепровести, а потом в расходной(которая уже есть) указать что продаёшь только допустим 1 "Стел1"- остальное стереть....и перепровести.....если заглянешь в движения дока, то увидишь что у тебя "Дет1" списывается с приходной накладной 1, но склад уже не транзитный(который и был указан у поступления), а основной...т.е. ты списал товар которого нет(раз набор измерений разный). Вот и минуса...
-
вопрос по задачке с расчетами.т.е. по 3.40
в начале темы у человека выложено решение, в нем имеется возможность ввода оклада.
вопрос?
всегда ли нужно делать ввод оклада и начтраивать как-то протяженные во времени расчеты, даже если про него ничего не сказано?
я чет не нашел в требваниях такого.
вопрос таков кароч:
нужно ли делать под оклад что- либо в задаче 3.40?
мое мнение что не нужно.оно верное ли?
-
Решила БУ с учетом всех особенностей, посмотрите, пожалуйста.
-
Загляни в свою базу Билета 6 и посмотри не в отчете, а в регистре остатки(Получи остатки по счету товары через консоль) и ты увидишь что у тебя минуса. Это ошибка происходит т.к. указываются разные наборы значений измерений. Выходит тогда что нужно партионно списывать только в разрезе склада шапки или делать два ресурса.....я не стал заморачиваться и усложнять себе задачу и сделал списание партий в разрезе склада.
До меня наконец-то дошло. Не идет ресурс количество в разрезе партия склад.
Переделал с двумя ресурсами. Заморочек, кстати, не много. В нужном месте нужно брать нужный ресурс и писать сразу в два. Изменения кода минимальны.
Спасибо ;)
-
Quantum81 - Ну гуд! Непонятно только насколько это оптимально....использование такого количества признаков учета субконто и ресурсов.
-
Решила БУ с учетом всех особенностей, посмотрите, пожалуйста.
pewit. БУ с той же ошибкой. Если я списываю по фифо и допустим со склада "транзит", первый приход был на "основной".... то тоже будут минуса...Или делаешь доп.ресурсы и признаки учета субконто или же списание по партиям делаешь в разрезе склада шапки. Т.к. Условие в задаче звучит так "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", а не "Себестоимость товара рассчитывается в разрезе ВСЕХ партий поступления этого товара." и не "Себестоимость товара рассчитывается в разрезе партий поступления этого товара НА СКЛАД УКАЗАННЫЙ В ШАПКЕ ДОКУМЕНТА.". То смело додумываешь сам(И аргументируешь в пояснении). Обычно если в задаче требуется сделать как либо конкретно то это чётко и точно поясняться. И там уже без вариантов. А здесь - творчество! pewit - Давно готовишься?
-
вопрос по задачке с расчетами.т.е. по 3.40
в начале темы у человека выложено решение, в нем имеется возможность ввода оклада.
вопрос?
всегда ли нужно делать ввод оклада и начтраивать как-то протяженные во времени расчеты, даже если про него ничего не сказано?
я чет не нашел в требваниях такого.
вопрос таков кароч:
нужно ли делать под оклад что- либо в задаче 3.40?
мое мнение что не нужно.оно верное ли?
Если в задаче сказано что не нужно значит не нужно, но если в задаче это не уточняется, то нужно. Если в задаче не будет ничего сказано про документ поступление ты его будешь делать, будешь тратить время на его создание? Если в задаче например ОУ не проговаривается что нужно контролировать остатки, то ты будешь тратить время на реализацию механизма?
-
привет.
карочи.
ТУКАНТУМ
пв оу косячина мен не понятно зачем делать запрос потом для выбора потрохов, потом писать движения , потом снова запрос.???
Смысел мне не ясен.
в целом все гут.Тока я бы при БУ сделал бы в три щага запрос.
проще как то его анализировать.
или с консоли притащил бы.
по рег бух я бы сам так же настроил его .
сумма баланосвый признак учета суммовой.у склада нет суммы.
получаю себестоимость по номенк и партии .
количество по складу.
однострокой пишем номен партия склад количество себестоимостьНаКоличество.
///////\
и я не совсем понял на тему минусов.
вроде написано себестоимость по партиям, значит все по партиям без учета склада.
минусов быть вроде не должно.
и их вроеде нет в решении
-
ааа, кароч догнал про минуса.
тогда чтобы минусов не было.
выбирать нужно остатки по партии и по складу отдельно.
с списко = мин(осталосьсписать, вд.количествоПоскладу, вд.количествопо партии);
ну и итоги по колиеству по парти смотреть также .
-
pewit - Давно готовишься?
Почти 2 месяца. Смотрела по блокам всё, сейчас собираю билеты целиком. Хотела до нового года закончить и поехать сдавать, но что-то уже сомневаюсь.
А ты?
Ой, какая-то мутная задача... Спасибо!
-
pewit - Давно готовишься?
Почти 2 месяца. Смотрела по блокам всё, сейчас собираю билеты целиком. Хотела до нового года закончить и поехать сдавать, но что-то уже сомневаюсь.
А ты?
Ой, какая-то мутная задача... Спасибо!
Leo_dialog ЕСЛИ ВЫ ПОДЕЛИЛИСЬ СВОЕЙ ПОЧТОЙ, УДАЛИТЕ СООБЩЕНИЕ НЕМЕДЛЕННО ИЛИ БУДЕТЕ ЗАБАНЕНЫ. ЧИТАЙТЕ ПРАВИЛА!!! mail.ru - Лучше на почту или скайп "qumoclass", чтоб здесь не по теме не писать.
На это и рассчитаны видимо задачи - сбить с толку, а так они просты).
5й - пошел. Последний. 23 декабря сдача. Из Задачника 50% каждого вида учета выполнено. Теперь билеты, 7ой идёт. Какаю либо предметную область знаешь на хорошо(ОУ, БУ СПР или УФ)? И после спеца желание есть на спец по УТ, БП?
-
СПР:
Спец по СПР предложил мне сделать 4 ВР, вместо 3х. а именно, фиксированную сумму поделить на 2 ВР
1) Оклад с 0-й суммой,чтобы брать часы факт
2)Фикс.Сумма - ДопНачисления. (т.к. он тут явно доп-ник)
+ ко всему, если пользователю дать возможность вводить в ТЧ несколько раз Фикс.Сумму, то он обязательно ее начислит. Т.е. если ввести фикс.сумму с 10-15, 20-25 числа, то фикс.сумма начислится в двойном размере)
Кто что думает по поводу этого?)
-
Часть БУ
Очень странно, я его решение крутил часа полтора. Я вводил туда данные во всех возможных комбинациях, все проверял через консоль запросов. Таблица итогов закрывалась. При этом, когда я смотрел код, я видел, что не будет здесь закрываться. Потом разобрался. Скачаю сейчас твое, посмотрю что там.
На самом деле, если смотреть отдельно по складу, и отдельно по партиям, закрывается. В том виде, какой отчет требуется, всё норм. А вот если посмотреть сам регистр, то по комбинации (партия,склад) идут расхождения, что впрочем, логично, т.к. мы по складу приходуем одни партии, а списываем другие.
Впрочем, уже есть идея - создать 2 ресурса с количеством, с разными признаками учета, думаю, что-то из этого получить можно будет.
Или как у Романа. Но на мой взгляд, всё же формулировка задачи требует списывать партии независимо от склада, поэтому попробую поработать с доп ресурсом.
Пришла к выводу, что решение Романа правильное, чтобы там другие не говорили
Мне кажется большинство не заметило фразу в условии:
Продажа товара производится со склада и регистрируется документом «Расходная накладная»
-
СПР:
Спец по СПР предложил мне сделать 4 ВР, вместо 3х. а именно, фиксированную сумму поделить на 2 ВР
1) Оклад с 0-й суммой,чтобы брать часы факт
2)Фикс.Сумма - ДопНачисления. (т.к. он тут явно доп-ник)
+ ко всему, если пользователю дать возможность вводить в ТЧ несколько раз Фикс.Сумму, то он обязательно ее начислит. Т.е. если ввести фикс.сумму с 10-15, 20-25 числа, то фикс.сумма начислится в двойном размере)
Кто что думает по поводу этого?)
Мне всё же кажется полностью фиксированную сумму должен получить сотрудник за полностью отработанный месяц, иначе не было бы фразы про "...методом отклонения"
-
СПР:
Спец по СПР предложил мне сделать 4 ВР, вместо 3х. а именно, фиксированную сумму поделить на 2 ВР
1) Оклад с 0-й суммой,чтобы брать часы факт
2)Фикс.Сумма - ДопНачисления. (т.к. он тут явно доп-ник)
+ ко всему, если пользователю дать возможность вводить в ТЧ несколько раз Фикс.Сумму, то он обязательно ее начислит. Т.е. если ввести фикс.сумму с 10-15, 20-25 числа, то фикс.сумма начислится в двойном размере)
Кто что думает по поводу этого?)
А что мешает нам писать фиксированную сумму в запись Оклад? Мы будем брать данные графика, чтобы посчитать часы, поэтому нам уже никуда не деться от периода действия. А что будет в ресурсе Результат - нулевая сумма или сотни тысяч, компьютеру все равно.
-
СПР:
Спец по СПР предложил мне сделать 4 ВР, вместо 3х. а именно, фиксированную сумму поделить на 2 ВР
1) Оклад с 0-й суммой,чтобы брать часы факт
2)Фикс.Сумма - ДопНачисления. (т.к. он тут явно доп-ник)
+ ко всему, если пользователю дать возможность вводить в ТЧ несколько раз Фикс.Сумму, то он обязательно ее начислит. Т.е. если ввести фикс.сумму с 10-15, 20-25 числа, то фикс.сумма начислится в двойном размере)
Кто что думает по поводу этого?)
А что мешает нам писать фиксированную сумму в запись Оклад? Мы будем брать данные графика, чтобы посчитать часы, поэтому нам уже никуда не деться от периода действия. А что будет в ресурсе Результат - нулевая сумма или сотни тысяч, компьютеру все равно.
так понимаю, что если задана фикс.сумма 4000 и мы вводим в один месяц 2 периода (10-15 и с 20-25числа), то получим что сотруднику в месяц начислят 8 000, вместо положенных 4000
-
Действительно, вы правы. Все оказалось сложнее, чем я думал.
-
Действительно, вы правы. Все оказалось сложнее, чем я думал.
Да, я вот тоже о таких "подводных камнях" не задумалась. Однако, тут отписывались, что в этом году задача попалась с условием, что берем не Отработанные дни, а Рабочие. Тогда все упрощается и в основной ВР не надо пихать пустой оклад. Можно смело Фикс.сумму в Доп.начисления кидать ...
Что касаемо БУ... подверглась всеобщей панике, что получаются минуса. Проверьте, пожалуйста.
Списание делаю т.о. : Беру остатки товара по складу и остатки общие в партии, а так же общую сумму партии. Связываю между собой их по партии. т.о. мы знаем сколько по партии остатков конкретно этого товара по складу.
Мне кажется, фраза "Продажа товара производится со склада и регистрируется документом «Расходная накладная»"
Списываем отношения товара со склада внутри этой партии к сумме всех товара по партии
PS все таки возьму слова обратно по поводу решения Романа. Хотя оно и имеет место быть.
-
Действительно, вы правы. Все оказалось сложнее, чем я думал.
Да, я вот тоже о таких "подводных камнях" не задумалась. Однако, тут отписывались, что в этом году задача попалась с условием, что берем не Отработанные дни, а Рабочие. Тогда все упрощается и в основной ВР не надо пихать пустой оклад. Можно смело Фикс.сумму в Доп.начисления кидать ...
Да даже при текущем условии, если пользователь ввел в документ оклад двумя периодами, есть выход, чтобы не заводить начисление без оплаты. Фиксированную сумму подтягиваем в первую попавшуюся запись, а если есть еще такая запись "Сотрудник, ВидРасчета", то там сумма ноль.
-
Действительно, вы правы. Все оказалось сложнее, чем я думал.
Да, я вот тоже о таких "подводных камнях" не задумалась. Однако, тут отписывались, что в этом году задача попалась с условием, что берем не Отработанные дни, а Рабочие. Тогда все упрощается и в основной ВР не надо пихать пустой оклад. Можно смело Фикс.сумму в Доп.начисления кидать ...
Да даже при текущем условии, если пользователь ввел в документ оклад двумя периодами, есть выход, чтобы не заводить начисление без оплаты. Фиксированную сумму подтягиваем в первую попавшуюся запись, а если есть еще такая запись "Сотрудник, ВидРасчета", то там сумма ноль.
Допустим, я провела так один документ.... тогда надо иметь ввиду, что можно создать новый документ и ввести опять, что с такого то- по такое число сотрудник работал, ... т.о. наверно лучше это все делать в общем модуле и проверять были ли за расчетный период такие начисления(т.е. делать не к записи ТЧ)
-
Цитата: "Метод отклонений — расчет времени выполняется на основании периодов отклонений от нормального графика работы. Фактически использованное время рассчитывается исходя из нормы времени, зафиксированной в общем графике работы учреждения или в индивидуальном графике работы сотрудника с учетом всех отклонений от этого графика, введенных различными документами (по причине отпуска, болезни, командировки и т. п.)."
Источник здесь:
http://v8.1c.ru/budghrm/test/wt.htm?printversion=1
Какой может быть смысл вводить несколько записей (без разницы, в одном документе или в разных) начисления ВР, фактически отработанное время по которому получается по формуле "Норма за месяц минус отклонения"?
-
Цитата: "Метод отклонений — расчет времени выполняется на основании периодов отклонений от нормального графика работы. Фактически использованное время рассчитывается исходя из нормы времени, зафиксированной в общем графике работы учреждения или в индивидуальном графике работы сотрудника с учетом всех отклонений от этого графика, введенных различными документами (по причине отпуска, болезни, командировки и т. п.)."
Источник здесь:
http://v8.1c.ru/budghrm/test/wt.htm?printversion=1
Какой может быть смысл вводить несколько записей (без разницы, в одном документе или в разных) начисления ВР, фактически отработанное время по которому получается по формуле "Норма за месяц минус отклонения"?
По счастливой случайности, в этой задаче не допускается использование различных графиков. А вот если бы допускалось, то можно было бы разбить такую запись в середине месяца для смены графика. Может это специально так задумано - нет смены графиков, значит можно включать в задачу фиксированную сумму, чтобы совсем уже не усложнять.
-
ну а как же классическое принялся/уволился в середине месяца?
-
ну а как же классическое принялся/уволился в середине месяца?
Это не тот случай, т.к. запись одна и не возникнет сомнений, что фиксированную сумму нужно писать именно в нее.
-
Цитата: "Метод отклонений — расчет времени выполняется на основании периодов отклонений от нормального графика работы. Фактически использованное время рассчитывается исходя из нормы времени, зафиксированной в общем графике работы учреждения или в индивидуальном графике работы сотрудника с учетом всех отклонений от этого графика, введенных различными документами (по причине отпуска, болезни, командировки и т. п.)."
Источник здесь:
http://v8.1c.ru/budghrm/test/wt.htm?printversion=1
Какой может быть смысл вводить несколько записей (без разницы, в одном документе или в разных) начисления ВР, фактически отработанное время по которому получается по формуле "Норма за месяц минус отклонения"?
По счастливой случайности, в этой задаче не допускается использование различных графиков. А вот если бы допускалось, то можно было бы разбить такую запись в середине месяца для смены графика. Может это специально так задумано - нет смены графиков, значит можно включать в задачу фиксированную сумму, чтобы совсем уже не усложнять.
Хм, перечитал условие: "Сотрудники работают на автомобилях предприятия, поэтому возможен обмен автомобилями между водителями. Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно."
Значит, графики, всё же, могут меняться. Так что может быть несколько строк. Зато в разных документах записи по одному ВР быть не могут ("Документ в расчетом периоде может быть один (сразу для всех видов расчета), а может быть несколько (по одному для каждого отдельного вида расчета)").
-
Что касаемо БУ... подверглась всеобщей панике, что получаются минуса. Проверьте, пожалуйста.
Списание делаю т.о. : Беру остатки товара по складу и остатки общие в партии, а так же общую сумму партии. Связываю между собой их по партии. т.о. мы знаем сколько по партии остатков конкретно этого товара по складу.
Мне кажется, фраза "Продажа товара производится со склада и регистрируется документом «Расходная накладная»"
Списываем отношения товара со склада внутри этой партии к сумме всех товара по партии
PS все таки возьму слова обратно по поводу решения Романа. Хотя оно и имеет место быть.
Да, задача интересная! по БУ.
margaritka47729 , вы не могли бы выгрузить в 8.3.6.2100 ( у вас 8.3.7) - у меня не загружает, а этот релиз не могу найти. Хотел бы глянуть, тоже делаю 6 билет БУ закончил.
Посмотрел тут решения - ни у кого и вправду не верно)) Кажись. Нужно смотреть остаток товара на складе, проверять на минуса. Для себестоимости - думаю нужно брать Партии товара принадлежащие нашему Складу, а не все Партии всех Складов. Вообщем смотрим: на Складе хватает товара - начинаем списывать Партии(по Фифо Лифо) - но только нашего склада.(а не все партии,с других складов - есть тут такие решения).
Вопрос по Отчёту - крутил - не могу понять как в Сборнике, чтобы Сумма не считалась по Складам(крутил Ресурсы, "рассчитывать по", отключал итоги у группировок - всё без толку ;-)) там все просто думаю - но СКД пока так себе...
Гляньте ОУ и БУ ?
-
Вот нашел в 4ом билете:
"Себестоимость товара рассчитывается для каждой организации в разрезе партий и складов по каждой номенклатурной позиции."
В 6оим билете:
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
по мне так задача именно на это, а то слишком легко там получалось. хотя два ресурса количество смотрятся не привычно.
-
Вот нашел в 4ом билете:
"Себестоимость товара рассчитывается для каждой организации в разрезе партий и складов по каждой номенклатурной позиции."
В 6оим билете:
Себестоимость товара рассчитывается в разрезе партий поступления этого товара
по мне так задача именно на это, а то слишком легко там получалось. хотя два ресурса количество смотрятся не привычно.
Предлагаете брать Себестоимость = СуммаВсехПартий/ КолВоВсехПартий, независимо от Склада - так партии не закроются в 0. Это же метод "По Средней" - где Партии вообще не имеют смысла.(вспомните задачу о смене учетной политики на "По Средней")....
тут же ФИФО/ЛИФО , внутри каждой партии - своя себестоимость. Главный Вопрос - какие партии брать для списания. Ну, только те, которые пришли на ДАННЫЙ склад(в шапке), их упорядочить и списывать.
-
zorky я об том и толкую. Если в разрезе складов - то как в условии 4го билета.
Хотя в 6-ои билете и такая фраза есть:
"Требуется реализовать возможность ведения учета товаров в разрезе мест хранения и партий товаров"
но все-таки эта фраза поконкретней:
"Себестоимость товара рассчитывается в разрезе партий поступления этого товара"
-
Что касаемо БУ... подверглась всеобщей панике, что получаются минуса. Проверьте, пожалуйста.
Списание делаю т.о. : Беру остатки товара по складу и остатки общие в партии, а так же общую сумму партии. Связываю между собой их по партии. т.о. мы знаем сколько по партии остатков конкретно этого товара по складу.
Мне кажется, фраза "Продажа товара производится со склада и регистрируется документом «Расходная накладная»"
Списываем отношения товара со склада внутри этой партии к сумме всех товара по партии
PS все таки возьму слова обратно по поводу решения Романа. Хотя оно и имеет место быть.
Да, задача интересная! по БУ.
margaritka47729 , вы не могли бы выгрузить в 8.3.6.2100 ( у вас 8.3.7) - у меня не загружает, а этот релиз не могу найти. Хотел бы глянуть, тоже делаю 6 билет БУ закончил.
Посмотрел тут решения - ни у кого и вправду не верно)) Кажись. Нужно смотреть остаток товара на складе, проверять на минуса. Для себестоимости - думаю нужно брать Партии товара принадлежащие нашему Складу, а не все Партии всех Складов. Вообщем смотрим: на Складе хватает товара - начинаем списывать Партии(по Фифо Лифо) - но только нашего склада.(а не все партии,с других складов - есть тут такие решения).
Вопрос по Отчёту - крутил - не могу понять как в Сборнике, чтобы Сумма не считалась по Складам(крутил Ресурсы, "рассчитывать по", отключал итоги у группировок - всё без толку ;-)) там все просто думаю - но СКД пока так себе...
Гляньте ОУ и БУ ?
Вот задача в нужной версии.) Отпишитесь как посмотрите, очень интересно мнение)
а на счет отчета - в условном оформлении по группировке "детальные записи"(или склад, у кого как) ставите пустой текст для данного ресурса . Еще раз повторюсь, что действия конкретно для группировки делать, не для вкладки "Отчет" в настройках :)
-
Вот задача в нужной версии.) Отпишитесь как посмотрите, очень интересно мнение)
а на счет отчета - в условном оформлении по группировке "детальные записи"(или склад, у кого как) ставите пустой текст для данного ресурса . Еще раз повторюсь, что действия конкретно для группировки делать, не для вкладки "Отчет" в настройках :)
О, спасибо ! Отчёт действительно такой как в задании)) Никогда бы не подумал про условное оформление полей!!!
Интересно, зачем тогда нужны "Рассчитывать по..." у ресурсов ...вообщем СКД надо подтягивать)
И ещё, я оказывается невнимательно прочитал условие 6 го билета, Склад то в ТЧ...сделал в шапке) А самое главное - подняли панику, которой я тоже поддался получается))) У вас считаю - правильное решение, кол-во по Складу, Себестоимость - в разрезе партий...(на Складе) Всё просто, 2 левых соединения)) в 0 закрывает, условия все выполненны. Почему у кого-то минуса возникали? не догоняю... точно, надо делать перерывы в подготовке - а то крышак едет немного) Моё решение выше - не совсем верное, и запрос усложнённый(зачем тянул Склад -не пойму), ну да ладно. Может кто посмотрит решение margaritka47729 , у кого "минуса" возникали?
По мелочи: на Склад нету блокировки(сужение пространства блокировки), пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). "Исключительный" - по умолчанию.... в запросе ISNULL нужен обязательно при Левом Соединении, (-1 балл?).
По моему достаточно одного Массива Параметров Субконто, с 3-мя Характеристиками. Хотя тут не знаю. Вопрос....знатокам!! Может ли такое быть что В Вашем случае во втором Регистре (где 2 параметра) - наоборот замедляется выборка(т.к. тип 3-го Субконто он не знает, но знает что их 3 ??? Даже если Субконто3 не используется? ))) ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?)
-
zorky минуса возникали потому что списывали по партиям в разрезе всей организации, а не в разрезе партий на складе.
-
zorky минуса возникали потому что списывали по партиям в разрезе всей организации, а не в разрезе партий на складе.
Ага, спасиб, сам же об этом выше писал ....))) щас СПР делаю, БУ "вылетело" временно из башки ))
Посмотрел ещё раз решение с 2-мя ресурсами, просто списываете все партии без учета Склада, а как списать с "Основного" то, что лежит на Транзитном? ))) Склады схлопываются в 0 у вас потому что 2 ресурса с разными признаками субконто))- ... весело! может быть, этого хотели Создатели задачи...не знаю..)
"Себестоимость в разрезе партий" - тогда может быть, написали бы "Списывать в разрезе партий (плевать на Склад)"-но тогда зачем проверять Остаток )))) у вас получается, если на "Основном" - хватает Товара, - отлично! Списываем с "Транзитного" и прочих ! а если не хватает - извините, нельзя провести документ-не хватает))
-
списывается не транзитных и прочих, а с партий. Т.е. тут как с двумя РН в ОУ.
Проверяю остаткок на складе, а списываю в разрезе партий. На склад не плевать - для того и была первая проверка.
-
списывается не транзитных и прочих, а с партий. Т.е. тут как с двумя РН в ОУ.
Проверяю остаткок на складе, а списываю в разрезе партий. На склад не плевать - для того и была первая проверка.
ну вот, на первой проверке покажет, что хватает товара на складе "Основной" и разрешит списание.
а списывать поехали с партии, которая поставила этот товар на "Транзитный".
-
Посмотри задачу ОУ 1-го билета. Здесь тоже самое, но на одном регистре бухгалтерии. В ОУ не тоже самое будешь делать? Проверишь остатки по одному РН, а списывать будешь и по этому и по другому, который в разрезе партий хранит остатки и себестоимость.
-
Посмотри задачу ОУ 1-го билета. Здесь тоже самое, но на одном регистре бухгалтерии. В ОУ не тоже самое будешь делать? Проверишь остатки по одному РН, а списывать будешь и по этому и по другому, который в разрезе партий хранит остатки и себестоимость.
Да, согласен, там: "Для расчета себестоимости при списании товара необходимо учитывать только момент поступления товара в компанию, вне зависимости от того, на какой склад он пришел". - это прямо оговорено)) Условия,мягко скажем,далеки от реальных ))) ну вообщем на экзамене главное пояснить грамотно.
Посмотрите СПР этого билета, кому не лень?
Сделал вид Расчета Время (отработанный период) - с ПД, и Отпуск с ПД.
Доп.Расчеты: ФиксОклад, Надбавка и решил сделать СреднийДневнойЗароботок. Его тоже рассчитваю, и помещаю в регистр, для красоты)) Оплаты от пассажиров в РН. В Отчёт не попадают не нужные виды расчета. Необходима суровая критика ;)
-
Вот задача в нужной версии.) Отпишитесь как посмотрите, очень интересно мнение)
а на счет отчета - в условном оформлении по группировке "детальные записи"(или склад, у кого как) ставите пустой текст для данного ресурса . Еще раз повторюсь, что действия конкретно для группировки делать, не для вкладки "Отчет" в настройках :)
О, спасибо ! Отчёт действительно такой как в задании)) Никогда бы не подумал про условное оформление полей!!!
Интересно, зачем тогда нужны "Рассчитывать по..." у ресурсов ...вообщем СКД надо подтягивать)
И ещё, я оказывается невнимательно прочитал условие 6 го билета, Склад то в ТЧ...сделал в шапке) А самое главное - подняли панику, которой я тоже поддался получается))) У вас считаю - правильное решение, кол-во по Складу, Себестоимость - в разрезе партий...(на Складе) Всё просто, 2 левых соединения)) в 0 закрывает, условия все выполненны. Почему у кого-то минуса возникали? не догоняю... точно, надо делать перерывы в подготовке - а то крышак едет немного) Моё решение выше - не совсем верное, и запрос усложнённый(зачем тянул Склад -не пойму), ну да ладно. Может кто посмотрит решение margaritka47729 , у кого "минуса" возникали?
По мелочи: на Склад нету блокировки(сужение пространства блокировки), пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). "Исключительный" - по умолчанию.... в запросе ISNULL нужен обязательно при Левом Соединении, (-1 балл?).
По моему достаточно одного Массива Параметров Субконто, с 3-мя Характеристиками. Хотя тут не знаю. Вопрос....знатокам!! Может ли такое быть что В Вашем случае во втором Регистре (где 2 параметра) - наоборот замедляется выборка(т.к. тип 3-го Субконто он не знает, но знает что их 3 ??? Даже если Субконто3 не используется? ))) ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?)
Спасибо за указание ошибок, :) постараюсь обосновать
пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). - не соглашусь, т.к. в моем случае я смотрю общ.сумму по партии при списании, чтобы рассчитать свою себестоимость. (партия может включать и другие склады с другими товарами, по условию себестоимость рассчитывается в пределах партии, а не склада).
ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?) - на сколько мне известно неявный запрос это когда обращение через точку в объектной модели(Выборка.Товар.Вид или просто Товар.Вид), я же просто взяла уже готовые данные из запроса... Хотелось бы еще услышать мнений и по поводу субконто тоже интересно.
-
Посмотри задачу ОУ 1-го билета. Здесь тоже самое, но на одном регистре бухгалтерии. В ОУ не тоже самое будешь делать? Проверишь остатки по одному РН, а списывать будешь и по этому и по другому, который в разрезе партий хранит остатки и себестоимость.
Хочу видеть ваше решение этой задачи БУ:) Не могли бы Вы выложить?
Постараюсь сегодня выложить решение вашим способом. Но, помнится, когда я решала 1й раз так,то у меня выходил минус
-
Вот задача в нужной версии.) Отпишитесь как посмотрите, очень интересно мнение)
а на счет отчета - в условном оформлении по группировке "детальные записи"(или склад, у кого как) ставите пустой текст для данного ресурса . Еще раз повторюсь, что действия конкретно для группировки делать, не для вкладки "Отчет" в настройках :)
О, спасибо ! Отчёт действительно такой как в задании)) Никогда бы не подумал про условное оформление полей!!!
Интересно, зачем тогда нужны "Рассчитывать по..." у ресурсов ...вообщем СКД надо подтягивать)
И ещё, я оказывается невнимательно прочитал условие 6 го билета, Склад то в ТЧ...сделал в шапке) А самое главное - подняли панику, которой я тоже поддался получается))) У вас считаю - правильное решение, кол-во по Складу, Себестоимость - в разрезе партий...(на Складе) Всё просто, 2 левых соединения)) в 0 закрывает, условия все выполненны. Почему у кого-то минуса возникали? не догоняю... точно, надо делать перерывы в подготовке - а то крышак едет немного) Моё решение выше - не совсем верное, и запрос усложнённый(зачем тянул Склад -не пойму), ну да ладно. Может кто посмотрит решение margaritka47729 , у кого "минуса" возникали?
По мелочи: на Склад нету блокировки(сужение пространства блокировки), пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). "Исключительный" - по умолчанию.... в запросе ISNULL нужен обязательно при Левом Соединении, (-1 балл?).
По моему достаточно одного Массива Параметров Субконто, с 3-мя Характеристиками. Хотя тут не знаю. Вопрос....знатокам!! Может ли такое быть что В Вашем случае во втором Регистре (где 2 параметра) - наоборот замедляется выборка(т.к. тип 3-го Субконто он не знает, но знает что их 3 ??? Даже если Субконто3 не используется? ))) ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?)
Спасибо за указание ошибок, :) постараюсь обосновать
пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). - не соглашусь, т.к. в моем случае я смотрю общ.сумму по партии при списании, чтобы рассчитать свою себестоимость. (партия может включать и другие склады с другими товарами, по условию себестоимость рассчитывается в пределах партии, а не склада).
ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?) - на сколько мне известно неявный запрос это когда обращение через точку в объектной модели(Выборка.Товар.Вид или просто Товар.Вид), я же просто взяла уже готовые данные из запроса... Хотелось бы еще услышать мнений и по поводу субконто тоже интересно.
1.Да, здесь разобрался, опять же смотрел по своему "неправильно прочитанному" решению. (склад в шапке ПН)
2.Готовые данные у вас типа Ссылка, и он побежит искать Представление для выдачи на экран...(неявный запросик) иначе он бы выдавал на экран Ссылку: 34dghgfh45w6w45ghxg00988выghfgh - в таком виде ))
по субконто, кажись просто лишняя писанина руками, один раз все 3 указать и всё. Смысл ещё раз указывать если Субконто3 не выбирается.... Имхо.
Посмотрите если время есть СПР, выше выложил(красивый отчёт у Вас украл ;-)
-
Вот задача в нужной версии.) Отпишитесь как посмотрите, очень интересно мнение)
а на счет отчета - в условном оформлении по группировке "детальные записи"(или склад, у кого как) ставите пустой текст для данного ресурса . Еще раз повторюсь, что действия конкретно для группировки делать, не для вкладки "Отчет" в настройках :)
О, спасибо ! Отчёт действительно такой как в задании)) Никогда бы не подумал про условное оформление полей!!!
Интересно, зачем тогда нужны "Рассчитывать по..." у ресурсов ...вообщем СКД надо подтягивать)
И ещё, я оказывается невнимательно прочитал условие 6 го билета, Склад то в ТЧ...сделал в шапке) А самое главное - подняли панику, которой я тоже поддался получается))) У вас считаю - правильное решение, кол-во по Складу, Себестоимость - в разрезе партий...(на Складе) Всё просто, 2 левых соединения)) в 0 закрывает, условия все выполненны. Почему у кого-то минуса возникали? не догоняю... точно, надо делать перерывы в подготовке - а то крышак едет немного) Моё решение выше - не совсем верное, и запрос усложнённый(зачем тянул Склад -не пойму), ну да ладно. Может кто посмотрит решение margaritka47729 , у кого "минуса" возникали?
По мелочи: на Склад нету блокировки(сужение пространства блокировки), пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). "Исключительный" - по умолчанию.... в запросе ISNULL нужен обязательно при Левом Соединении, (-1 балл?).
По моему достаточно одного Массива Параметров Субконто, с 3-мя Характеристиками. Хотя тут не знаю. Вопрос....знатокам!! Может ли такое быть что В Вашем случае во втором Регистре (где 2 параметра) - наоборот замедляется выборка(т.к. тип 3-го Субконто он не знает, но знает что их 3 ??? Даже если Субконто3 не используется? ))) ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?)
Спасибо за указание ошибок, :) постараюсь обосновать
пусть нашу Номенклатуру в момент транзакции списывают с других Складов, нам это пофиг). - не соглашусь, т.к. в моем случае я смотрю общ.сумму по партии при списании, чтобы рассчитать свою себестоимость. (партия может включать и другие склады с другими товарами, по условию себестоимость рассчитывается в пределах партии, а не склада).
ну и ПРЕДСТАВЛЕНИЕ(Номенклатура) нужно по идее выбирать - а то неявный запросик в цикле при выдаче сообщения...(-0.1 балл?) - на сколько мне известно неявный запрос это когда обращение через точку в объектной модели(Выборка.Товар.Вид или просто Товар.Вид), я же просто взяла уже готовые данные из запроса... Хотелось бы еще услышать мнений и по поводу субконто тоже интересно.
1.Да, здесь разобрался, опять же смотрел по своему "неправильно прочитанному" решению. (склад в шапке ПН)
2.Готовые данные у вас типа Ссылка, и он побежит искать Представление для выдачи на экран...(неявный запросик) иначе он бы выдавал на экран Ссылку: 34dghgfh45w6w45ghxg00988выghfgh - в таком виде ))
по субконто, кажись просто лишняя писанина руками, один раз все 3 указать и всё. Смысл ещё раз указывать если Субконто3 не выбирается.... Имхо.
Посмотрите если время есть СПР, выше выложил(красивый отчёт у Вас украл ;-)
По отчету не критичные замечания: "конец" - лучше приводить на конец дня, и если пользователь выбирает период, то лучше параметры дат задавать через компоновщик запроса, иначе если пытаться посмотреть все начисления за все периоды, то отчет вылетит с ошибкой
СрДневЗар - все такие лишнее.
Все расчеты должны быть в общ.модуле
Запрос в выборке другого запроса- честно говоря, вообще кажется непонятной жестью) лучше так не делать. Да и честно говоря, не вижу смысле по РС тут что то отдельно рассчитывать..
-
По отчету не критичные замечания: "конец" - лучше приводить на конец дня, и если пользователь выбирает период, то лучше параметры дат задавать через компоновщик запроса, иначе если пытаться посмотреть все начисления за все периоды, то отчет вылетит с ошибкой
СрДневЗар - все такие лишнее.
Все расчеты должны быть в общ.модуле
Запрос в выборке другого запроса- честно говоря, вообще кажется непонятной жестью) лучше так не делать. Да и честно говоря, не вижу смысле по РС тут что то отдельно рассчитывать..
Спасибо!) Параметры да, только у меня почему-то когда ничего не указываешь, ничего и не выходит))) ну да ладно)
насчёт Конца Периода. Мы же Период Регистрации смотрим, а он всегда 1-е число, расчётного периода, ВСЕ начисления ноября (даже 23:59:59) будут зареганы 1-го числа, и в отчёт попадут. (даже если предположить, что начислили в тот самый момент, между 59-ой секундой, и Новым днём, т.е. Граница.Включая, то думаю ПР и ПД этой записи будут 1-м числом этого расчётного периода.
Это актуально для Регистра Накопления (Остатки), берём остатки на 23:59:59 - могут быть неверные данные. Поэтому здесь добавляем +1 секунду к концу периода...(включая её) с РН(Обороты) - по умолчанию включает границу.
мм... не пойму, как это: Запрос в Выборке другого Запроса. ))) не увидел, у меня первый запрос вытаскивает Базу и Отработанные Дни, рассчитываем СрЗароботок. Следующий Запрос - тянет из РС "Графики" рабочие дни по пятидневке. (их больше не откуда взять, кроме как из РС, а вы как предлагаете :-) ?
-
... Следующий Запрос - тянет из РС "Графики" рабочие дни по пятидневке. (их больше не откуда взять, кроме как из РС, а вы как предлагаете :-) ?
Получение данных графика через таблицу регистра сведений -2 балла.
Почему не получить норму рабочего времени из таблицы ДанныеГрафика, предварительно указав для нужной записи соотв график?
И что это за РР ОтработанныеДни, он что, только для хранения отработанного времени? Это явно лишнее.
И да, очень не рекомендуется расчеты производить в процедуре проведения.
-
... Следующий Запрос - тянет из РС "Графики" рабочие дни по пятидневке. (их больше не откуда взять, кроме как из РС, а вы как предлагаете :-) ?
Получение данных графика через таблицу регистра сведений -2 балла.
Почему не получить норму рабочего времени из таблицы ДанныеГрафика, предварительно указав для нужной записи соотв график?
И что это за РР ОтработанныеДни, он что, только для хранения отработанного времени? Это явно лишнее.
И да, очень не рекомендуется расчеты производить в процедуре проведения.
блин, -2 балла это серьёзно)) да,спасибо, взял из ДанныхГрафика.
Регистр "Отработанные дни" - это чтобы вводить отработанное Время - чтобы считать дни по разным графикам....он с ПД. Здесь же Отпуск с ПД.
Регистр "Начисления" - без ПД... Здесь Надбавка и ФиксОклад и Ср.Зарботок )
Кроме Ср.ДневЗароботка - по моему всё красиво ) Можно было и без него, согласен.
-
Решил вернуться к задаче БУ этого билета.
Здесь в ветке я для себя отметил два решения
- Решение Романа, но у него соединение двух таблиц остатков по партиям, то есть себестоимость считается неправильно.
- Решение Quantum81, но у него три ресурса в регистре бухгалтерии. Судя по коду, там себестоимость должна правильно считаться, проверить не смог.
Также были проверены некоторые другие решения.
Методика проверки:
Заводим новую номенклатуру Тест. Создаем приходную накладную 01.12.2015 по складу Склад1, в строке Тест, количество 2, сумма 20. Создаем приходную накладную 02.12.2015 по складу Склад2, в строке Тест, количество 3, сумма 40. Учетную политику ставим ФИФО.
Создаем расходную накладную, склад Склад2, в строке Тест, количество 3, сумма 500 (без разницы какая сумма продажи).
Себестоимость трех единиц должна получиться 33.33, из них 20 спишутся с первой партии, 13.33 - со второй партии.
У всех, у кого соединение таблиц остатков по партиям, себестоимость получается 40, то есть все списывается со второй партии.
В своем решении я не стал заморачиваться с учетной политикой, пусть она всегда будет ФИФО, это не важно, всегда можно доделать.
Отрицательных остатков нет.
Выкатываю для обсуждения свое решение.
-
СуммаПродажи = 0;
СуммаПродажи = СуммаПродажи + ВыборкаНом.Количество;
.....
Движение.Сумма = СуммаПродажи;помарка.
Но проверить то тоже не просто :)
Т.е. смысл в том что если партия списания и склад не совпадают, мы делаем две проводки - одну с нулевым Количество и одну с нулевой суммой?
-
СуммаПродажи = 0;
СуммаПродажи = СуммаПродажи + ВыборкаНом.Количество;
.....
Движение.Сумма = СуммаПродажи;помарка.
Но проверить то тоже не просто :)
Т.е. смысл в том что если партия списания и склад не совпадают, мы делаем две проводки - одну с нулевым Количество и одну с нулевой суммой?
Ну в моем примере количество - это одни проводки, сумма - другие. И рассчитываются эти проводки раздельно. То есть партионное списание происходит дважды, но в одном не трогаем сумму, а в другом не трогаем количество и партии там другие.
-
у меня не прокатило, или я не пойму что это за строчка
-
так, вроде разобрался. Имхо, работать не будет. В первый раз будет правильное списание, потом поплывет себестоимость. Хотя регистр думаю закроется. Не уверен. Тяжело в голове уложить.
Чтобы пропорционально списать сумму с партии, нам нужно количество партии, а его ты менять не будем, мы количество только спишем в разрезе партия-склад.
-
Вообще полезла сюда смотреть СПР, несколько непонятная задача, а прочитала тут истерию по БУ, только что ее решила ведь, сама запаниковала в процессе чтения ветки, но протестировав по методу Zeskord получила нужный результат: 20 и 13. Фуууф.. можно выдохнуть.... У меня 2 таблицы в запросе (другие решения не смотрела) УправленческийОстаткиСклад и УправленческийОстаткиПартия. в параметрах склада указываю и склад и номенклатуру из ТЧ, а в партиях только номенклатуру. Связи по номенклатуре обеих таблиц с ТЧ. как-то так.... Галка "суммовой" на складе снята.
-
Решил вернуться к задаче БУ этого билета.
Здесь в ветке я для себя отметил два решения
- Решение Романа, но у него соединение двух таблиц остатков по партиям, то есть себестоимость считается неправильно.
- Решение Quantum81, но у него три ресурса в регистре бухгалтерии. Судя по коду, там себестоимость должна правильно считаться, проверить не смог.
Также были проверены некоторые другие решения.
Методика проверки:
Заводим новую номенклатуру Тест. Создаем приходную накладную 01.12.2015 по складу Склад1, в строке Тест, количество 2, сумма 20. Создаем приходную накладную 02.12.2015 по складу Склад2, в строке Тест, количество 3, сумма 40. Учетную политику ставим ФИФО.
Создаем расходную накладную, склад Склад2, в строке Тест, количество 3, сумма 500 (без разницы какая сумма продажи).
Себестоимость трех единиц должна получиться 33.33, из них 20 спишутся с первой партии, 13.33 - со второй партии.
У всех, у кого соединение таблиц остатков по партиям, себестоимость получается 40, то есть все списывается со второй партии.
В своем решении я не стал заморачиваться с учетной политикой, пусть она всегда будет ФИФО, это не важно, всегда можно доделать.
Отрицательных остатков нет.
Выкатываю для обсуждения свое решение.
Привет Zeskord)
Скачал твоё решение.
Разобрал.
У тебя количество списалось, а сумма осталась т.е. теперь не минуса, а постоянный зависший плюс. Один фиг это не сведение в 0...Если смотреть через консоль остатки по счету товары.
Прикрепляю...
Там введены доки, там 2 поступления и два списания.
Просто загляни консолью в остатки.
И по поводу неправильно.
Если не было бы условия "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", то как бы ты списывал: По средней в разрезе склада, по средней всего товара , или по партии. А тут, если читать задачу сверху в низ, то это как уточнение того что списание со склада, а в разрезе склада идёт партионное списание(Ведь если бы не условие, то можно и по средней было додумать). Так ведь? Если ты хочешь сделать списание в разрезе всех партий, то без ресурса никак. Это же явно видно!
-
И по поводу неправильно.
Если не было бы условия "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", то как бы ты списывал: По средней в разрезе склада, по средней всего товара , или по партии. А тут, если читать задачу сверху в низ, то это как уточнение того что списание со склада, а в разрезе склада идёт партионное списание(Ведь если бы не условие, то можно и по средней было додумать). Так ведь? Если ты хочешь сделать списание в разрезе всех партий, то без ресурса никак. Это же явно видно!
Когда я сдавал, ждал своей очереди, я слышал, как экзаменатор песочил сдающего, которому попалась такая задача. Он ему говорил "ты считаешь себестоимость в разрезе партий на склад, а в условии сказано в разрезе партий, не зависимо от склада".
-
И по поводу неправильно.
Если не было бы условия "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", то как бы ты списывал: По средней в разрезе склада, по средней всего товара , или по партии. А тут, если читать задачу сверху в низ, то это как уточнение того что списание со склада, а в разрезе склада идёт партионное списание(Ведь если бы не условие, то можно и по средней было додумать). Так ведь? Если ты хочешь сделать списание в разрезе всех партий, то без ресурса никак. Это же явно видно!
Когда я сдавал, ждал своей очереди, я слышал, как экзаменатор песочил сдающего, которому попалась такая задача. Он ему говорил "ты считаешь себестоимость в разрезе партий на склад, а в условии сказано в разрезе партий, не зависимо от склада".
Вот самый кайф это когда ты лично с экзаменатором говоришь!)) Вот тут и вступает в силу то как Ты умеешь объяснять свою точку зрения. Как Ты понял задачу. Он тебе и ничего и не скажет в условии нет конкретного указания что "В РАЗРЕЗЕ ВСЕХ СКЛАДОВ". Я это писал ранее. Поэтому отстаивай свою точку зрения. Или стой опустив глаза.
А самое забавное в этом экзамене: что один экзаменатор посчитает ошибкой на балл, то второй может и ничего не сказать в одной и той же задаче.
Тут очень много описаний сдающих с подобным сюжетом...поэтому и надо отстаивать как ты понял задание. Если конечно там нет явной формулировки задания.
Да и ткни мне носом где здесь такая формулировка в задаче. "А В УСЛОВИИ СКАЗАНО В РАЗРЕЗЕ ПАРТИЙ, НЕЗАВИСИМО ОТ СКЛАДА".
Мы спорим непонятно о чем. Если ты понял что нужно так делать, так реши задачу в своём понимании и выложи мы дружно оценим.
-
...как Ты умеешь объяснять свою точку зрения...
Думаю, относительно данной задачи т.з., при которой партии по одному складу, всё же будет ошибочной.
Еще раз перечитал, вспомнил свой старый аргумент в пользу того, что партии не зависят от склада. Читаем вместе 2 фразы:
"Требуется реализовать возможность ведения учета товаров в разрезе мест хранения и партий товаров... Себестоимость товара рассчитывается в разрезе партий поступления этого товара."
Поскольку учет в целом в разрезе партий и складов, то 2-я фраза акцентирует именно отсутствие зависимости себестоимости от склада, а не наличие некой зависимости от партии (раз уж учет по партиям, то смысл в нем именно лишь для расчета себестоимости, количество же в любой партии будет для учета абсолютно одинаково :) ). И тем более нет смысла повторять отдельно для себестоимости тоже самое, что уже сказано для всего учета.
Вообще, со своей т.з. надо быть осторожнее - если она не соответствует убеждению экзаменатора и у него есть (небезосновательная) уверенность в том, что верна именно она, доказать обратное может быть довольно проблематично. :)
-
непонятно, есть ли правильное решение БУ без использования 2-х ресурсов? Или это единственный вариант...
-
Мое решение, в БУ присоединяю регистр с количеством по партии и складу к ДокТЧ, и присоединяю второй регистр с суммами к первому регистру по субконто номенклатура и субконто партия, все должно быть правильно
-
Вот, решил самую интересную задачу БУ из Актуальных))
Решение: Сч. Товары - просто Номенклатура и Сумма.
Технический(вспомогательный Счёт) - Движение Товаров. Без субконто.
И 2 Счёта: Товары На Складах, Партии Товаров.(с субконтами Ном, Партии и Склады где оно надо)
1 билет ОУ показал путь решения) Регистры д.б. независимы друг от друга, в данном случае Счета. Думаю методически правильное решение. И на экзамене в принципе, можно успеть сделать наверное.
Схема решения проста - приходуем на Товары, на Товары на Складах, и На Товары в партиях. В ходе решения думал - как в типовых происходит приём товаров, и разбивается по субсчетам. Основной счёт(Товары) должен корреспондировать с Поставщиками. А эти товары надо ещё раскидать на склады и партии)) Для этого был введён Вспомогательный Счёт "Движение товаров". Сначала хотел Забалансовый - а нельзя)) Ну а потом прикинул - искажения учёта не должно быть, откуда забрали - туда и вернём при продаже. Кто знает типовые, как там реализовано? Время нету их ковырять пока)) про УТ 11 малось почитал - ну там понятно куча регистров Остатков Товаров для разных нужд. В БП интересует. Думаю - приблизительно также и реализовано? )
Протестил 100 раз, всё ровно выходит в 0. Копейки, партии , отчёт готов. - ну вообщем идеальное решение. Посмотрите плиз. (кстати, решение с 2 мя ресурсами так и не посмотрел, думаю там тоже правильно - но решил по своему сделать, методически верно. Ведь два ресурса количеств для разных сущностей - это...ну не знаю вообщем)) Прошу оценить!(особенно мнение тех кто дико обсуждал эту ветку, Роман, alex1248, Zeskord, Quantum81 и Olga1c, кстати у последней, подозреваю - всё же не верно с двумя соединениями. В минус уйдёт по количеству, а себестоимость - верная)
-
Сч. Товары - просто Номенклатура и Сумма.
Технический(вспомогательный Счёт) - Движение Товаров. Без субконто.
И 2 Счёта: Товары На Складах, Партии Товаров.(с субконтами Ном, Партии и Склады где оно надо)
1 билет ОУ показал путь решения)
Не совсем понял. Как же понять без базы и хотя бы описания проводок. :)
Скажу однако, что бухгалтерские счета - это не полный аналог регистров накопления, и в общем случае дублирование учета одних и тех же объектов не приветствуется (хотя, наверное, если исключить возможность возникновения суммарно отличных от нуля остатков по доп счету/счетам, организовать такой учет можно. Но всё же я не уверен, что экзаменатор отнесется к такой идее с должным пониманием). По поводу типовой - вроде бы, в ней нет такого возможности такого запутанного учета ТМЦ между партиями и складами (и для бухучета это логично, он же как правило ведется не в управленческих целях, так что смысла мудрить обычно не возникает) - либо учитывается, либо нет: в каких разрезах учитывается, по тем же и рассчитывается себестоимость списания. Но если бы были возможности такого учета, то, думаю, использовались бы дополнительные РН, коих в типовой БП довольно много для разнообразных дополнительных нужд.
Вот еще подумал - док "Операция" - при оприходовании товара с его использованием вероятность корректного ввода с использованием доп счетов или РН снижается.
Никто отзыв о сдаче с этой задачей не писал? Может быть ее на экз уже давно не дают? :)
Да, теперь я наверное для реализации реального проекта выбрал бы вариант с доп РН. Хотя с однозначной рекомендацией выбора того или иного варианта для экз затрудняюсь. :)
-
Сч. Товары - просто Номенклатура и Сумма.
Технический(вспомогательный Счёт) - Движение Товаров. Без субконто.
И 2 Счёта: Товары На Складах, Партии Товаров.(с субконтами Ном, Партии и Склады где оно надо)
1 билет ОУ показал путь решения)
Не совсем понял. Как же понять без базы и хотя бы описания проводок. :)
Скажу однако, что бухгалтерские счета - это не полный аналог регистров накопления, и в общем случае дублирование учета одних и тех же объектов не приветствуется (хотя, наверное, если исключить возможность возникновения суммарно отличных от нуля остатков по доп счету/счетам, организовать такой учет можно. Но всё же я не уверен, что экзаменатор отнесется к такой идее с должным пониманием). По поводу типовой - вроде бы, в ней нет такого возможности такого запутанного учета ТМЦ между партиями и складами (и для бухучета это логично, он же как правило ведется не в управленческих целях, так что смысла мудрить обычно не возникает) - либо учитывается, либо нет: в каких разрезах учитывается, по тем же и рассчитывается себестоимость списания. Но если бы были возможности такого учета, то, думаю, использовались бы дополнительные РН, коих в типовой БП довольно много для разнообразных дополнительных нужд.
Вот еще подумал - док "Операция" - при оприходовании товара с его использованием вероятность корректного ввода с использованием доп счетов или РН снижается.
Никто отзыв о сдаче с этой задачей не писал? Может быть ее на экз уже давно не дают? :)
Да, теперь я наверное для реализации реального проекта выбрал бы вариант с доп РН. Хотя с однозначной рекомендацией выбора того или иного варианта для экз затрудняюсь. :)
Блин! Как всегда забыл базу приклеить! идиотизм))
Да, согласен, с доп.РН - самый правильный вариант. Точняк. Получается что задача Смешана с ОУ-механизмами. А я показал чисто на БУ. ) и да, "операцей" сложно будет вводить три проводки....)))) Но всё же вот - выкладываю, оцените плиз.
-
Но всё же вот - выкладываю, оцените плиз.
Похоже, что корректные данные получить можно. Но лично я не стал бы в таком виде делать задачу по бухучету. :)
-
Но всё же вот - выкладываю, оцените плиз.
Похоже, что корректные данные получить можно. Но лично я не стал бы в таком виде делать задачу по бухучету. :)
Т.е. вариант с доп. регистрами по ОУ был бы предпочтительней? Но ведь получается, что задача по БУ будет решена на регистрах ОУ, в БУ останется один основной Счет "Товары", Субктоно "Номенклатура" кол и сумма. Всмысле механизмы регистра БУ вообще почти не будут использованы))) всё таки с 2-мя ресурсами и 2 признаками учёта субконто - будет корректнее, считаете?
-
всё таки с 2-мя ресурсами и 2 признаками учёта субконто - будет корректнее, считаете?
В вашем варианте я сформировал оборотную ведомость по счетам, выглядит не очень, бух не поймет такого - это непонятное дублирование количества и сумм по товарам. :)
В реальном проекте сделал бы с доп РН.
Для экз - да, доп ресурс для количества. Он же все равно не балансовый, и будет рассчитываться лишь для одного счета, думаю, большой нагрузки от него не будет. К тому же задача в этом случае полностью решается на РБ.
-
Мне попадалась данная задача на экзамене, с двумя ресурсами.
Принимал Аксенов, сказал, что как-то бредово решено, очень сложно. Как "проще" решить - не сказал.
Проверил сведение регистра в ноль с пом. консоли - не свелся (видимо, я что-то не так решил, хотя дома потом еще раз прорешал эту задачу - все сводилось в ноль).
-
Мне попадалась данная задача на экзамене, с двумя ресурсами.
Принимал Аксенов, сказал, что как-то бредово решено, очень сложно. Как "проще" решить - не сказал.
Проверил сведение регистра в ноль с пом. консоли - не свелся (видимо, я что-то не так решил, хотя дома потом еще раз прорешал эту задачу - все сводилось в ноль).
Надо по методу Zeskord проверить, чтобы партия была первой(по фифо) а склад не из этой партии, с которого в расходке списываете.
Алекс1248, да уж, самое верное с доп регистром ОУ "Партии". На очном так и скажу, если попадётся. Сошлюсь на типовую БУ.)
а вот если Аксенов говорит про "проще" ... хз как делать-то) значит с 2-мя ресурсами - не вариант?
-
Мне попадалась данная задача на экзамене, с двумя ресурсами.
Принимал Аксенов, сказал, что как-то бредово решено, очень сложно. Как "проще" решить - не сказал.
Проверил сведение регистра в ноль с пом. консоли - не свелся (видимо, я что-то не так решил, хотя дома потом еще раз прорешал эту задачу - все сводилось в ноль).
Надо по методу Zeskord проверить, чтобы партия была первой(по фифо) а склад не из этой партии, с которого в расходке списываете.
Алекс1248, да уж, самое верное с доп регистром ОУ "Партии". На очном так и скажу, если попадётся. Сошлюсь на типовую БУ.)
а вот если Аксенов говорит про "проще" ... хз как делать-то) значит с 2-мя ресурсами - не вариант?
Почему, думаю, что вариант - просто я как-то некорректно решил тогда, если бы решил корректно - списалось бы все в 0 и, думаю, решение было бы принято. Не было слов про "методологически неверно".
А вот если в БУ использовать данные РН - это сразу - 2 или сколько-то там баллов (см. список ошибок) - не советовал бы.
-
Как вам такое решение билета? Как вариант в БУ я разделил движения по счету Товары на движения по складу без суммы и движения по партиям без склада. Решение не очень елегантное но счет закрывается в ноль. Правда отчет вышел сложнее. Буду благодарен за конструктивную критику.
-
вот и мой вариант 6-го билета, в основных начислениях сделала только Отпуск
-
Как вам такое решение билета?... в БУ
БУ - не очень (остальное не смотрел).
Даже отчеты формируются некорректно.
Пример. Получаю остатки на сегодня. Стойка высокая: приходы 20 шт на 3000 и 10 шт на 2100, расход 10 шт на 1500 (смотрю по проводке). В остатке должно быть10 шт на 3600, у вас же сумма 7200 (предположительно, сумма задвоилась). Не стал разбираться почему, хотя по Болт М12 вроде бы верно. Возможно, зависит от того, на скольких складах есть остаток.
Ну и из кода видно, что будет задваивание количества по номенклатуре. Такого отчета нет, но можно проверить, например, с помощью консоли запросов.
-
Как вам такое решение билета?... в БУ
БУ - не очень (остальное не смотрел).
Даже отчеты формируются некорректно.
Пример. Получаю остатки на сегодня. Стойка высокая: приходы 20 шт на 3000 и 10 шт на 2100, расход 10 шт на 1500 (смотрю по проводке). В остатке должно быть10 шт на 3600, у вас же сумма 7200 (предположительно, сумма задвоилась). Не стал разбираться почему, хотя по Болт М12 вроде бы верно. Возможно, зависит от того, на скольких складах есть остаток.
Ну и из кода видно, что будет задваивание количества по номенклатуре. Такого отчета нет, но можно проверить, например, с помощью консоли запросов.
Спасибо большое. Еще раз перепроверил, да действительно много ошибок. Потом подумал и решил что по сути сам себе усложняю жизнь. И реально задача решается гараздо проще чем я думал. Во-первых Обработка проведение приходной накладной должна быль как и у всех аналогичных задачах билетов - без отдельного проведения по складах и по-партиях. Во-вторых в расходной накладной в запросе необходимо к данным документа присоединить виртуальную таблицу остатков партий товара на складе Регистра Бухгалтерии Счета Товары (субконто Товар, Склад, Партия) - для поля КоличествоОстатокСклад, и виртуальную таблицу остатков партий товара (вне зависимости от склада) Регистра Бухгалтерии Счета Товары (субконто Товар, Партия). Порядок в контексте Партий. Итоги - Сумма(КоличествеОстатокСклад) - это общий итог Номенклатуры на Складе, Максимум(Количество) - это количество Номенклатуры, которое необходимо списать. А дальше остается всего лишь реализовать стандартную процедуру списания. В результате и отчеты можно сформировать очень просто и без задвоения строк.
А вот и моя выгрузка
-
Вчера вернулся к задачи БУ из этого билета. Перечитал всю тему и понял, что раньше решал неправильно, билет один из самых мудреных по БУ. Все таки надо решать на двух ресурсах КоличествоПартия и КоличествоСклад, как тут предлагали коллеги. Билет действительно аналог задачи ОУ из 1 Билета, где два РН с разным ресурсом Количество и думаю, что "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" об этом четко говорит, хотя...
Последние решения приведенные здесь списывают партии, которые поступали именно на склад списания, а в условии себестоимость по "всем" и тут писали, что препод на экзамене именно про это уточнил. Перерешал, сейчас регистр закрывается в 0 независимо от того на какой склад поступила партия.
-
тогда признак учета количественный лишний, у вас все количество на признаке учета субконто
-
Да-да, как раз сделал с двумя ресурсами - давно не мог добраться. ) Посмотреть выше не у всех вышло - 8.3.7 релиз Платформы ещё не нашёл ;)) и не грузятся задача Veron - но я думаю у него уже очень близко к правильному решению(ага, как подметила cheb73 - ПУ "Количественный" - тут не нужен - но это мелочь )) Другие решения(без 2 ресурсов, с 2 мя соединениями) - 99% НЕ верные ))) Повозился с отчётом, пришлось всё таки соединять 2 РБ, и Ресурс берётся Минимум(или Максимум)...
Гляньте, в общем на 2 ресурсах будем делать если попадётся ;-)
-
Ребят, есть кто-то решавший задачу БУ из этого билета на экзамене? Как все же верно решать?
Столько мнений разных.
Если не сложно поделитесь верным решением. Спасибо.
-
Следует учесть, что данные об отпуске не могут вводиться в систему задним числом.
кто что предпринимал с этой фразой? )
-
я думаю, это значит что все данные текущим периодом, сторно делать не нужно
-
По-моему по БУ многие запариваются (признаки учета или субконто доп. делают). Мне видеться это так: Если на складе есть это количество, то списываем. С/с считаем исходя из партий (несмотря на какой склад был приход товара в приходной). Поэтому признак учета количественный и суммовой убираем у склада. Что думаете по этому поводу?
-
По-моему по БУ многие запариваются (признаки учета или субконто доп. делают). Мне видеться это так: Если на складе есть это количество, то списываем. С/с считаем исходя из партий (несмотря на какой склад был приход товара в приходной). Поэтому признак учета количественный и суммовой убираем у склада. Что думаете по этому поводу?
а остатки на СКЛАДЕ тогда как контролировать ))
-
По-моему по БУ многие запариваются (признаки учета или субконто доп. делают). Мне видеться это так: Если на складе есть это количество, то списываем. С/с считаем исходя из партий (несмотря на какой склад был приход товара в приходной). Поэтому признак учета количественный и суммовой убираем у склада. Что думаете по этому поводу?
а остатки на СКЛАДЕ тогда как контролировать ))
Что значит как? Признак учета Количественный... 1. Приход товара(Накладная) - склад указывается в каждой строке 2. Расход - Склад в шапке. В процедуре проведения смотрим есть ли необх. кол товара, далее списываем сс по партиям, возникает ситуация, например, если мы в прих. №1 ручка - 2 -500-1000 (Склад1), ручка - 4-100 -400(Склад2). списываем 3 (Склад1)- не пройдет(в запросе есть условие по складу), списываем 1 сс = 1 / (2+4) * 1400 = 233,33. Потом решили списать 2 со Склад2, та же самая проверка на количество, списываем 2 сс = 2 / (1+4) * 1166, 67 = 466,67, ну так далее. Еще, например, приход1 ручка - 2 -100-200 Склад1 и приход2 ручка 200-5-1000 Склад 1. Списываем 3 ручки. Метод "первый пришел, первый ушел"(FIFO). Списание банальное. В РБ две записи: ручки 2 - 200 и ручка 1 - 5. В итоге сс 3х ручек -205 со Склада1. Может еще какие-нибудь подводные камни есть? Напишите кто как понимает.
-
По-моему по БУ многие запариваются (признаки учета или субконто доп. делают). Мне видеться это так: Если на складе есть это количество, то списываем. С/с считаем исходя из партий (несмотря на какой склад был приход товара в приходной). Поэтому признак учета количественный и суммовой убираем у склада. Что думаете по этому поводу?
а остатки на СКЛАДЕ тогда как контролировать ))
Что значит как? Признак учета Количественный... 1. Приход товара(Накладная) - склад указывается в каждой строке 2. Расход - Склад в шапке. В процедуре проведения смотрим есть ли необх. кол товара, далее списываем сс по партиям, возникает ситуация, например, если мы в прих. №1 ручка - 2 -500-1000 (Склад1), ручка - 4-100 -400(Склад2). списываем 3 (Склад1)- не пройдет(в запросе есть условие по складу), списываем 1 сс = 1 / (2+4) * 1400 = 233,33. Потом решили списать 2 со Склад2, та же самая проверка на количество, списываем 2 сс = 2 / (1+4) * 1166, 67 = 466,67, ну так далее. Еще, например, приход1 ручка - 2 -100-200 Склад1 и приход2 ручка 200-5-1000 Склад 1. Списываем 3 ручки. Метод "первый пришел, первый ушел"(FIFO). Списание банальное. В РБ две записи: ручки 2 - 200 и ручка 1 - 5. В итоге сс 3х ручек -205 со Склада1. Может еще какие-нибудь подводные камни есть? Напишите кто как понимает.
у вас не будет записи в регистре, сколько чего осталось на СКЛАДЕ, у вас будет ОБЩЕЕ количество Номенклатуры, на всех складах.
-
БУ делаю все- таки с ПУ Количественный, и ПУ субконто Суммовой. И так вертела, и по другому , все закрывается в ноль , нет отрицательных остатков, все остатки проверяю в консоле .
Единственное проверяю
Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстаток);
Если Выборка.КоличествоОстатокПартия = Списать Тогда
Себестоимость = Выборка.СуммаОстатокПартия;
Иначе
Себестоимость = Списать* Выборка.СуммаОстатокПартия/Выборка.КоличествоОстатокПартия;
КонецЕсли;
Гляньте кому не лень, где я не права
-
БУ делаю все- таки с ПУ Количественный, и ПУ субконто Суммовой. И так вертела, и по другому , все закрывается в ноль , нет отрицательных остатков, все остатки проверяю в консоле .
Единственное проверяю
Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстаток);
Если Выборка.КоличествоОстатокПартия = Списать Тогда
Себестоимость = Выборка.СуммаОстатокПартия;
Иначе
Себестоимость = Списать* Выборка.СуммаОстатокПартия/Выборка.КоличествоОстатокПартия;
КонецЕсли;
Гляньте кому не лень, где я не права
проверяем по методу Zeskord:
Методика проверки:
Заводим новую номенклатуру Тест. Создаем приходную накладную 01.12.2015 по складу Склад1, в строке Тест, количество 2, сумма 20. Создаем приходную накладную 02.12.2015 по складу Склад2, в строке Тест, количество 3, сумма 40. Учетную политику ставим ФИФО.
Создаем расходную накладную, склад Склад2, в строке Тест, количество 3, сумма 500 (без разницы какая сумма продажи).
Себестоимость трех единиц должна получиться 33.33, из них 20 спишутся с первой партии, 13.33 - со второй партии.
У всех, у кого соединение таблиц остатков по партиям, себестоимость получается 40, то есть все списывается со второй партии.
у вас - 40.
посмотрел по ЛИФО.
ставлю ФИФО - почему то 13 и 20 (без дробей)...
-
Разрядность не поставила , поэтому нет копеек.
Переделала еще раз, чтобы учитывались все партии , а не только те у которых хоть в одной строчке был нужный склад .
Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстаток); переделала т.к. нужно проверять Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстатокПартия);
Спасибо, что проверяете после успешной сдачи)
-
Разрядность не поставила , поэтому нет копеек.
Переделала еще раз, чтобы учитывались все партии , а не только те у которых хоть в одной строчке был нужный склад .
Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстаток); переделала т.к. нужно проверять Списать = МИН(ОсталосьСписать, Выборка.КоличествоОстатокПартия);
Спасибо, что проверяете после успешной сдачи)
Все почему то вначале наступают на эти грабли в этой задаче)) это хорошо, чтобы самому убедится что без 2 ресурсов(или 2 счетов, как я делал) - имхо, её решить нереально. Как ОУ в 1 задаче без 2-х регистров...
При проведении Расходки у вас в запрос не попадает Склад, у вас всё будет списывать с одного склада, отсюда и минуса по этому складу пойдут, по Субконто Склад - РБ не схлопнется. Проверьте методом Zeskord.
-
Привет всем, я продолжаю бестолковиться)), вижу, что есть решения и они логически правильные (на мой взгляд), но есть решение, которое короче, а вот правильное ли? Писал о нем чуть выше, мне ответили что нет возможности отследить по складам количество - проверял, вроде норм. Приходовал на разные склады, списание происходит как надо (или я не понял до конца условие задачи). Посмотрите, выскажитесь.
-
Набила тестовые данные с вашим количеством и суммой, списалось первые две 20 , третья 13,33 . Потом на всякий случай еще списала с первого склада 2 штуки, чтобы проверить что суммы не зависли. Все хорошо
-
Набила тестовые данные с вашим количеством и суммой, списалось первые две 20 , третья 13,33 . Потом на всякий случай еще списала с первого склада 2 штуки, чтобы проверить что суммы не зависли. Все хорошо
У вас не по средней списывается, в этой задаче нужно использовать ПУ Субконто
-
Набила тестовые данные с вашим количеством и суммой, списалось первые две 20 , третья 13,33 . Потом на всякий случай еще списала с первого склада 2 штуки, чтобы проверить что суммы не зависли. Все хорошо
У вас не по средней списывается, в этой задаче нужно использовать ПУ Субконто
А почему должно по средней списываться? С/с "в разрезе партий поступления", а не "с/с считать, как среднюю по партиям".
-
в разрезе партий любых, вне зависимости от склада, а вы у себя в запросе делаете отбор по складу
-
в разрезе партий любых, вне зависимости от склада, а вы у себя в запросе делаете отбор по складу
Если я приходую прих№1 ручка- 6-200(Склад 1) и ручка - 3-300 (Склад 2), прих№2 ручка -2-2000(Склад 2), ручка 4-300 (Склад 2). Метод LIFO. С/с пяти ручек со Склада1? Я считаю, что 5/6 * 200, у вас же получиться, что 5/6 * 2300 (списываем из Прих№2, так как LIFO)
-
ну потому что вы учитываете склад при расчете суммы списания, а я нет. У нас просто с вами разное понимание задачи)
-
ну потому что вы учитываете склад при расчете суммы списания, а я нет. У нас просто с вами разное понимание задачи)
да, я это уже понял. похоже ваше правильнее, т.к. в моем случае некоторые прих. не будут учитываться, хотя должны бы
-
Набила тестовые данные с вашим количеством и суммой, списалось первые две 20 , третья 13,33 . Потом на всякий случай еще списала с первого склада 2 штуки, чтобы проверить что суммы не зависли. Все хорошо
у вас зависают не суммы а количества.
Списание происходит с одного склада, партия №00006 у вас приходила на склад Основной, а вы списываете его с Транзитного. В итоге у вас образуется запись -2 по Транзитному, по приходке №000006.На Основном эта партия как была, так и остаётся не тронутой ))
выгружаю с данными, для удобства удалил предыдущие приходки-расходки. Посмотрите.
-
спасибо большое)) Уперлась на сумму , проверяю остатки только по ней. Все голова уже совсем не соображает. Придется все-таки ПУ Субконто разносить. Хотелось без них обойтись, почти получилось))))
А вы делали еще одну проводку на другой счет?
-
спасибо большое)) Уперлась на сумму , проверяю остатки только по ней. Все голова уже совсем не соображает. Придется все-таки ПУ Субконто разносить. Хотелось без них обойтись, почти получилось))))
А вы делали еще одну проводку на другой счет?
:-)
ну мы все тут так мучались, так же казалось что вот-вот и выйдет "по человечески" решить, думали можно без 2-х ресурсов и 2-х ПУ субконто, многие пытались(я вообще сделал вариант с разными Счетами - в целом верно считает - но не красивые ОСВ и отчёты прочие получаются)))) дублирование данных.
Что за проводка на другой Счет? )
у меня в этой ветке лежит решение, последнее из выложенных по-моему, с 2 мя ресурсами и 2 ПУ субконто.
-
Здравствуйте, уважаемые коллеги.
Подскажите пожалуйста, при решении задачи по БУ не возникает ли проблема копеек? а то у меня на слово "себестоимость" уже рефлекс выработался с этими копейками.
Спасибо.
-
Здравствуйте, уважаемые коллеги.
Подскажите пожалуйста, при решении задачи по БУ не возникает ли проблема копеек? а то у меня на слово "себестоимость" уже рефлекс выработался с этими копейками.
Спасибо.
в данной задаче не должно быть, списывается вся сумма партии, если все количество
а сумма на складах не хранится
-
Цитата: Ads666sda от Марта 17, 2016, 12:15:06 pm
Здравствуйте, уважаемые коллеги.
Подскажите пожалуйста, при решении задачи по БУ не возникает ли проблема копеек? а то у меня на слово "себестоимость" уже рефлекс выработался с этими копейками.
Спасибо.
в данной задаче не должно быть, списывается вся сумма партии, если все количество
а сумма на складах не хранится
Спасибо большое за пояснение.
-
Мое решение
-
Мое решение
Задача БУ В документе «Приходная накладная» склад указывается в табличной части для каждой строки . А это многое меняет для проведения расходной
-
Мое решение
Задача БУ В документе «Приходная накладная» склад указывается в табличной части для каждой строки . А это многое меняет для проведения расходной
В моем решении склад в табличной части и есть
-
Доброго дня, коллеги!
На суд общественности.
ОУ и БУ задачи слабо совместимые - по условию - в ОУ склады в шапках, в БУ в приходной - в ТЧ, получается в приходной склады в 2-х местах :)
Также в ОУ номенклатура делится по видам - деталь и стеллаж, в БУ этого нет, пришлось в БУ списывать только детали, т.к. Приходная накладная соответственно может приходовать только детали.
Отличия:
ОУ достаточно типовая, ничего особенного. Единственное - новая методика списания.
БУ - жесть, как некоторые трактуют так вообще. Я делал в варианте удобоваримом - то есть списывается по партиям себестоимость, но только по тем, которые есть на данном складе.
Вообще это логично, в отличии от другого варианта, так как приходная накладная задает однозначную связь между складом и партией. Например, физически пришли 2 носок в партии 1 на склад 1, и еще 2 носок в партии 2 на склад 2. И, очень странно, например, списывать при продаже со склада 2 стоимость партии 1, так как физически эта партия на складе 1.
Но для общего развития попозже может попробую финт такой сделать.
СПР. График делал с 2 мя ресурсами - дни и дни пятидневки. Это позволяет обойтись без отдельного реквизита График.
В основные начисления вынес надбавку помимо отпуска, так как какой-то вид расчета должен фиксировать отработанные часы и он должен вытесняться отпуском есс-но.
-
Мое решение
Задача БУ В документе «Приходная накладная» склад указывается в табличной части для каждой строки . А это многое меняет для проведения расходной
В моем решении склад в табличной части и есть
скачала ваше решение еще раз
обработка проведения приходной накладной
Процедура ОбработкаПроведения(Отказ, Режим)
Движения.ОстаткиНоменклатуры.Очистить();
Движения.Управленческий.Очистить();
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПриходнаяНакладнаяСписокНоменклатуры.Номенклатура,
| СУММА(ПриходнаяНакладнаяСписокНоменклатуры.Количество) КАК Количество,
| СУММА(ПриходнаяНакладнаяСписокНоменклатуры.Сумма) КАК Сумма
|ИЗ
| Документ.ПриходнаяНакладная.СписокНоменклатуры КАК ПриходнаяНакладнаяСписокНоменклатуры
|ГДЕ
| ПриходнаяНакладнаяСписокНоменклатуры.Ссылка = &Ссылка
| И НЕ ПриходнаяНакладнаяСписокНоменклатуры.Номенклатура.Комплект
|
|СГРУППИРОВАТЬ ПО
| ПриходнаяНакладнаяСписокНоменклатуры.Номенклатура";
Запрос.УстановитьПараметр("Ссылка", Ссылка);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
Движение = Движения.ОстаткиНоменклатуры.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
Движение.Склад = Склад;
Движение.Номенклатура = ВыборкаДетальныеЗаписи.Номенклатура;
Движение.Количество = ВыборкаДетальныеЗаписи.Количество;
Движение = Движения.Управленческий.Добавить();
Движение.СчетДт = ПланыСчетов.Управленческий.Товары;
Движение.СчетКт = ПланыСчетов.Управленческий.Поставщики;
Движение.Период = Дата;
Движение.Сумма = ВыборкаДетальныеЗаписи.Сумма;
Движение.КоличествоДт = ВыборкаДетальныеЗаписи.Количество;
Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = ВыборкаДетальныеЗаписи.Номенклатура;
Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Партия] = Ссылка;
Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Склад] = Склад;
КонецЦикла;
// регистр ОстаткиНоменклатуры Приход
Движения.ОстаткиНоменклатуры.Записывать = Истина;
// регистр Управленческий
Движения.Управленческий.Записывать = Истина;
//{{__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
// Данный фрагмент построен конструктором.
// При повторном использовании конструктора, внесенные вручную изменения будут утеряны!!!
//}}__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
КонецПроцедуры
Склад из шапки . Может вы выложили не ту версию билета
-
Точно.Я выложил не свое решение(
Спасибо вам
-
спишите не по 10 ,а по 20 штук в каждой расходной накладной позиция Молоток и посмотрите остатки по товарам в консоле
-
Провел, остаток по рн = 0
-
Доброго дня, коллеги!
СПР. График делал с 2 мя ресурсами - дни и дни пятидневки. Это позволяет обойтись без отдельного реквизита График.
В основные начисления вынес надбавку помимо отпуска, так как какой-то вид расчета должен фиксировать отработанные часы и он должен вытесняться отпуском есс-но.
По СПР по-моему самая мутная задача, особенно в части графиков. Решение через 2 ресурса наверное самое красивое и работающее, но вот хз как к нему отнесутся на экзамене. В отзывах по этой теме ничего не нашел.
Только вот остался один вопрос - реквизит ТЧ Автомобиль при расчете отпуска. Какой автомобиль указывать в ТЧ при расчете отпуска? Ведь в расчете отпуска он не участвует, но в отчете Автомобиль нужен по каждому ВР, поэтому указывать нужно. Получается, что любой автомобиль от балды. Вот этот момент мне кажется довольно мутным и создается впечатление, что мы тут чего-то недоделали или не поняли. Может есть у кого какие мысли на этот счет?
-
Доброго дня, коллеги!
СПР. График делал с 2 мя ресурсами - дни и дни пятидневки. Это позволяет обойтись без отдельного реквизита График.
В основные начисления вынес надбавку помимо отпуска, так как какой-то вид расчета должен фиксировать отработанные часы и он должен вытесняться отпуском есс-но.
По СПР по-моему самая мутная задача, особенно в части графиков. Решение через 2 ресурса наверное самое красивое и работающее, но вот хз как к нему отнесутся на экзамене. В отзывах по этой теме ничего не нашел.
Только вот остался один вопрос - реквизит ТЧ Автомобиль при расчете отпуска. Какой автомобиль указывать в ТЧ при расчете отпуска? Ведь в расчете отпуска он не участвует, но в отчете Автомобиль нужен по каждому ВР, поэтому указывать нужно. Получается, что любой автомобиль от балды. Вот этот момент мне кажется довольно мутным и создается впечатление, что мы тут чего-то недоделали или не поняли. Может есть у кого какие мысли на этот счет?
Я исходил из вот этого: http://forum.chistov.pro/index.php?topic=2005.msg22307#msg22307
Хоть и информация 2012 года, но там сам Белоусов вроде отвечал, на второй странице кажется - есть уточнение по графикам, на что я и опираюсь.
А так - либо с 2 мя ресурсами, либо составной тип, где-то читал коммент, что вот такое решение с 2-мя ресурсами преподаватель не одобрил, хотя это были курсы, а не экзамен. Но Белоусову все же доверия побольше.
С автомобилями - не знаю. Мысли есть, а вот правильно или нет - неизвестно. Делаю на автомате такие вещи - так как подобных белых пятен в задачах много, особенно СПР.
По логике, автомобиль на время отпуска конечно не нужен, его может занять другой сотрудник. Пустым оставлять тоже некрасиво. В варианте с составным реквизитом Автомобиль/График тут можно указать пятидневку, она вылезет в отчете - криминала тут вроде бы нет, только некрасиво.
Вы кстати не в курсе - как правильно реализовывать "учетные данные разных периодов" в одном документе? А то тут ссылок и мнений преподавателей море - от того, что это просто разбитый на кусочки текущий месяц до периода регистрации в ТЧ. Я пока на среднем варианте остановился - период регистрации один в шапке, а вот считаются данные либо относительно периода действия либо относительно базового периода (для доп. начислений). Но уверенности нет.
-
Второй вариант решения БУ - на мой взгляд нелогичный, но возможно это и требуется в задаче. Остальной билет тоже решен, но ничем не отличается от 1-го варианта.
Списание партий отдельно от складов. Все просто, когда знаешь, что надо 2 отдельных ресурса.
Самое сложное было - понять почему все не списывается как надо :). Как оказалось, в режиме предприятия у обоих количеств стояли ВСЕ признаки учета субконто. Не первый раз - когда в конфигураторе настраиваешь как надо, а в предприятии получается как всегда. Пришлось в режиме предприятия пересоздать и настроить субконто.
-
Я исходил из вот этого: http://forum.chistov.pro/index.php?topic=2005.msg22307#msg22307
Хоть и информация 2012 года, но там сам Белоусов вроде отвечал, на второй странице кажется - есть уточнение по графикам, на что я и опираюсь.
А так - либо с 2 мя ресурсами, либо составной тип, где-то читал коммент, что вот такое решение с 2-мя ресурсами преподаватель не одобрил, хотя это были курсы, а не экзамен. Но Белоусову все же доверия побольше.
С автомобилями - не знаю. Мысли есть, а вот правильно или нет - неизвестно. Делаю на автомате такие вещи - так как подобных белых пятен в задачах много, особенно СПР.
По логике, автомобиль на время отпуска конечно не нужен, его может занять другой сотрудник. Пустым оставлять тоже некрасиво. В варианте с составным реквизитом Автомобиль/График тут можно указать пятидневку, она вылезет в отчете - криминала тут вроде бы нет, только некрасиво.
Вы кстати не в курсе - как правильно реализовывать "учетные данные разных периодов" в одном документе? А то тут ссылок и мнений преподавателей море - от того, что это просто разбитый на кусочки текущий месяц до периода регистрации в ТЧ. Я пока на среднем варианте остановился - период регистрации один в шапке, а вот считаются данные либо относительно периода действия либо относительно базового периода (для доп. начислений). Но уверенности нет.
Пасиб за ссылку, не видел ее даже.
Тему про "учетные данные разных периодов" я пока что решил отложить, единственное точно знаю, что вариант ПР в ТЧ использовать не буду.А просто разбитый на кусочки месяц не соответсвует логике: ведь данные разных РАСЧЕТНЫХ периодов,т.е. вне пределах текущего ПР.
Кстати, советую обратить внимание на информацию от специалиста, которому попался этот билет на экзамене. Мы с ним поговорили немного на эту тему недавно в конце темы 15-го билета. Вкратце - авто для отпуска можно оставлять пустым таки. Некрасиво, но логично.
-
Пасиб за ссылку, не видел ее даже.
Тему про "учетные данные разных периодов" я пока что решил отложить, единственное точно знаю, что вариант ПР в ТЧ использовать не буду.А просто разбитый на кусочки месяц не соответсвует логике: ведь данные разных РАСЧЕТНЫХ периодов,т.е. вне пределах текущего ПР.
Кстати, советую обратить внимание на информацию от специалиста, которому попался этот билет на экзамене. Мы с ним поговорили немного на эту тему недавно в конце темы 15-го билета. Вкратце - авто для отпуска можно оставлять пустым таки. Некрасиво, но логично.
Спасибо! Сейчас почитаю.
Почитал. Да, просто оставить пустым логично. Хотя так можно только когда есть еще реквизит (График) в РР и измерение График в РС составного типа. Но по вышеприведенной ссылке (Gyd) вроде бы было написано, что в случае когда только один график не основного типа, то надо доп. ресурс, а когда - несколько, тогда - составной тип. В случае с доп. ресурсом, как я сделал - не получится авто оставить пустым. Или заводить Авто для отпуска :).
-
Доброго времени суток!
Посмотрел несколько решений по СПР - назрел вопрос: получается, что отпуск не вытесняет фиксированную сумму оплаты? в основном Фикс выносят в Доп.Начисления и данный вид расчета ни от чего не зависит и ничем не вытесняется. Вроде бы и по условию также: "Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег". Но, по логике, странно платить Фикс, когда человек в отпуске. Прошу развеять мои сомнения, кто что думает по этому поводу?
-
Вроде бы осилил 6-й билет. Прошу специалистов посмотреть и раскритиковать.
Больше всего времени убил на СПР - почти весь день, а нужно весь билет решить за 5 часов - пока что это выглядит нереально :-\
СПР сделал так: Надбавка и Отпуск в ОН, Фикс в ДН. Отпуск вытесняет Надбавку, Фикс всегда начисляется, ничем не вытесняется. (это правильно?)
в РР ОснНачисления добавил еще ресурс "ОтработаноДней" для расчета базы по Отпуску. Сам Отпуск рассчитывается по графику пятидневка, для этого добавил в обработку заполнения графика условие - если автомобиль не выбран (пустая ссылка), тогда график заполняем как пятидневку. В документе НачислениеЗарплаты при выборе вида расчета Отпуск по логике автомобиль не указывают - т.е. это пустая ссылка, т.е. считаем как пятидневку.
Правильнее наверно было бы какой то предопределенный "автомобиль" завести и как то привязать его к отпуску, или составной реквизит сделать, но в условии не сказано про контроль этого момента, а через пустую ссылку получилось быстро и работает. Как считаете - не будет проблем?
-
СПР. Тоже пришел к мысли что лучше завести предопределенный "автомобиль для 5дневки" его и в РР писать
и доп. ресурс в графиках не нужен...
-
Выкладываю 6 билет. Времени на него ушло значительно больше чем на другие. Надеюсь он обойдет меня стороной на экзамене. Не заводил доп ресурс для пятидневки, т.к. придется тогда для каждого сотрудника заполнять этот ресурс одними и теми же значениями. Сделал, как реализовал когда-то на экзамене Alex1248 в регистре сведений ГрафикиРаботы и Регистре расчета поле составного типа (спр. Автомобиль+ перечисление СтандартныеГрафики)
-
Добрый день, дорогие форумчане!
У меня такой вопрос: считается ли очень страшным грехом использовать в БУ забалансовый счет - ТоварыНаСкладах (ПУ Количественный Субконто-Номенклатура,Склад,ПУС НЕ суммовой у обоих субконто) и нормальный счет Товары (ПУ Количественный Субконто-Номенклатура,Партия, ПУС суммовой у обоих субконто). Конструкция с двумя счетами кажется мне похожей решению аналогичной задачи в ОУ (с двумя РН). Или за забалансовый счет сильно штрафуют? Спасибо.
-
я не врубаюсь в эту задачу. Для фиксированной суммы график не нужен, для надбавки тоже. Их в дополнительные.
Только для отпуска.
Отпуск надбавку не может вытеснять. ФиксСумму непонятно, вроде не должен по условиям.
В основные начисления засунуть отпуск + ЯвкаНаРаботу(измерение сотрудник, ресурс ОтработаноДней)???
Или в основные только отпуск и отработано дней в базовом периоде считать из регистра сведений.
Как правильно???
Пипец что за мудень такие задачи придумывает. как хочешь так понимай
-
я не врубаюсь в эту задачу. Для фиксированной суммы график не нужен, для надбавки тоже. Их в дополнительные.
Только для отпуска.
Отпуск надбавку не может вытеснять. ФиксСумму непонятно, вроде не должен по условиям.
В основные начисления засунуть отпуск + ЯвкаНаРаботу(измерение сотрудник, ресурс ОтработаноДней)???
Или в основные только отпуск и отработано дней в базовом периоде считать из регистра сведений.
Как правильно???
Пипец что за мудень такие задачи придумывает. как хочешь так понимай
Сейчас в задаче отпуск рассчитывается по "рабочим" дням. Вид расчета ФиксированныйОклад делаете с периодом действия + ресурс регистра РабочихДней, в него пишите количество рабочих дней. Я так реализовывал на экзамене, нареканий не вызвало, затем при расчете отпуска собираете данные по базе, в том числе РабочихДнейБаза
-
ФиксированныйОклад в ОсновныеНачисления?
-
ФиксированныйОклад в ОсновныеНачисления?
Да, именно так. Иначе как собрать количество рабочих дней, если нет ни одного начисления с периодом действия?
-
Выкладываю 6 билет. Времени на него ушло значительно больше чем на другие. Надеюсь он обойдет меня стороной на экзамене. Не заводил доп ресурс для пятидневки, т.к. придется тогда для каждого сотрудника заполнять этот ресурс одними и теми же значениями. Сделал, как реализовал когда-то на экзамене Alex1248 в регистре сведений ГрафикиРаботы и Регистре расчета поле составного типа (спр. Автомобиль+ перечисление СтандартныеГрафики)
Решил еще раз решить эту задачу. Вот что заметил - есть такая фраза - Значение процента для надбавки может изменяться не чаще, чем один раз в месяц
Получается, что может быть 2 строки в РР если процент 1 раз изменился + сумма продаж делится на 2. Первая половина умножается на первое значение процента, вторая - на второе значение. Или я уже мудрю сильно?
В общем во вложении решение только СПР с учетом замечаний выше. В решении отчета нет, делал на скорость.
-
Доброй ночи, подскажите пожалуйста, вот в Регитсре Бухгалтерии Сумма идет с Признаком учета субконто Суммовой. а галочку балансовый нужно снимать?
-
этот билет в текущей редакции. задача по зарплате - нужно рассчитывать по регистру бухгалтерии (проводка Дебет касса Кредет поставщики). и вместо управляемых форм - бизнесс-процесс. Мне кажется там все задачи №4 по бизнесс-процессам
-
Решил еще раз решить эту задачу. Вот что заметил - есть такая фраза - Значение процента для надбавки может изменяться не чаще, чем один раз в месяц
Получается, что может быть 2 строки в РР если процент 1 раз изменился + сумма продаж делится на 2. Первая половина умножается на первое значение процента, вторая - на второе значение. Или я уже мудрю сильно?
Мне кажется, Вы уже не в ту степь полезли, мудрите чересчур.
Я на экзамене просто подтягивал на начало расчетного периода процент надбавки и умножал на сумму оплат пассажиров (по актуальному условию проводка Дт Касса, Кт Покупатели). Никакой проверки, что она введена несколько раз и каких-то чудачеств с делением суммы не делал и Вам не советую.
-
Доброй ночи, подскажите пожалуйста, вот в Регитсре Бухгалтерии Сумма идет с Признаком учета субконто Суммовой. а галочку балансовый нужно снимать?
А зачем снимать галочку "Балансовый"? - тогда Вам надо будет для каждой проводки одну и ту же сумму писать в поля СуммаДт и СуммаКт, с помощью признака учета субконта Вы отключаете ведение учета по сумме на субконто Склад, но суммовой учет в целом будет вестить на всех счетах
-
этот билет в текущей редакции. задача по зарплате - нужно рассчитывать по регистру бухгалтерии (проводка Дебет касса Кредет поставщики). и вместо управляемых форм - бизнесс-процесс. Мне кажется там все задачи №4 по бизнесс-процессам
За все не могу сказать, но в этой в актульной редакции действительно не задача по УФ, а задача по б/п, причем такая, которой нет ни в одном билете.
-
Доброй ночи, подскажите пожалуйста, вот в Регитсре Бухгалтерии Сумма идет с Признаком учета субконто Суммовой. а галочку балансовый нужно снимать?
А зачем снимать галочку "Балансовый"? - тогда Вам надо будет для каждой проводки одну и ту же сумму писать в поля СуммаДт и СуммаКт, с помощью признака учета субконта Вы отключаете ведение учета по сумме на субконто Склад, но суммовой учет в целом будет вестить на всех счетах
Спасибо большое. Все поняла. Готовлюсь и уже кругом голова, сомневаюсь уже во всем.
-
Спасибо большое. Все поняла. Готовлюсь и уже кругом голова, сомневаюсь уже во всем.
Тоже кстати этот вопрос (вроде бы элементарный) донимал перед экзаменом))) Удачи в подготовке! Скоро планируете сдавать?
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Может у Вас было другое условие задачи?
Описывали в пояснительной записке, почему сделали оклад фиксированным начислениям?
По условию задачи у меня для расчета средней дневной ставки отпуска необходимо было знать количество рабочих дней, я описал в пояснительной записке, что завел ресурс количество рабочих дней для накопления этих самих рабочих дней, а фиксированный оклад сделал с периодом действия, чтобы считать и записывать в ресурс регистра эти самые рабочие дни. Претензий по решению никаких не было.
-
Спасибо большое. Все поняла. Готовлюсь и уже кругом голова, сомневаюсь уже во всем.
Тоже кстати этот вопрос (вроде бы элементарный) донимал перед экзаменом))) Удачи в подготовке! Скоро планируете сдавать?
Совсем скоро уже 22 июляяяяяя, уже в четвертый раз пойду.
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Может у Вас было другое условие задачи?
Описывали в пояснительной записке, почему сделали оклад фиксированным начислениям?
По условию задачи у меня для расчета средней дневной ставки отпуска необходимо было знать количество рабочих дней, я описал в пояснительной записке, что завел ресурс количество рабочих дней для накопления этих самих рабочих дней, а фиксированный оклад сделал с периодом действия, чтобы считать и записывать в ресурс регистра эти самые рабочие дни. Претензий по решению никаких не было.
У меня такое же задание было. В пояснении не успел написать. Тут ежу уж понятно для чего туда суют фиксированный оклад. Не знаю кто там проверяет. Набрали наверное студентов, дали им методички. Если есть возможность надо вживую сдавать, а не дистанционно.
Еще методика проведения оперативной задачи не понравилассь - "В оперативном учете используется менее эффективная методика проведения". Я так понимаю надо было но "новой" методике проводить.
-
pozitiFFF, для чего вы в обработке проведения расходной накладной используете Менеджер временных таблиц. Вроде вы дальше ее не используете. И зачем в первом запросе расх накл создаете временную таблицу
-
Еще методика проведения оперативной задачи не понравилассь - "В оперативном учете используется менее эффективная методика проведения". Я так понимаю надо было но "новой" методике проводить.
Да, в этой задаче новая без вариантов, себестоимость же вообще не учитывается, списывать можно без дополнительных расчетов.
-
Совсем скоро уже 22 июляяяяяя, уже в четвертый раз пойду.
Ого. Ну надеюсь завтра будет успешно! Удачи на сдаче!
-
Еще методика проведения оперативной задачи не понравилассь - "В оперативном учете используется менее эффективная методика проведения". Я так понимаю надо было но "новой" методике проводить.
Да, в этой задаче новая без вариантов, себестоимость же вообще не учитывается, списывать можно без дополнительных расчетов.
я вот не совсем понимаю почему без вариантов. в чем преимущество для этой задачи новой методики? количество запросов вроде такое же
-
Еще методика проведения оперативной задачи не понравилассь - "В оперативном учете используется менее эффективная методика проведения". Я так понимаю надо было но "новой" методике проводить.
Да, в этой задаче новая без вариантов, себестоимость же вообще не учитывается, списывать можно без дополнительных расчетов.
я вот не совсем понимаю почему без вариантов. в чем преимущество для этой задачи новой методики? количество запросов вроде такое же
Для экзамена без вариантов.
Вот тут можете про принципиальные отличия прочитать:
http://1c.chistov.pro/2010/06/1-82.html
-
Еще методика проведения оперативной задачи не понравилассь - "В оперативном учете используется менее эффективная методика проведения". Я так понимаю надо было но "новой" методике проводить.
Да, в этой задаче новая без вариантов, себестоимость же вообще не учитывается, списывать можно без дополнительных расчетов.
я вот не совсем понимаю почему без вариантов. в чем преимущество для этой задачи новой методики? количество запросов вроде такое же
Для экзамена без вариантов.
Вот тут можете про принципиальные отличия прочитать:
http://1c.chistov.pro/2010/06/1-82.html
если бы не надо соединяться с регистром сведений в любом случае, то да без вариантов. для этой задачи мне кажется нет особой разницы
-
Ребят, если кому не сложно или даже интересно, просмотрите мой билет, желательно покритиковать его. Это по-моему, самый вредный билет из все, что есть.
-
Люди, посмотрите пжлста.
Почему в модуле РасходнаяНакладная, во втором запросе, при попытке поставить условие "Номенклатура в (Выбрать ВТ.Номенклатура из Док как ВТ)" в РегистреНакопления.Остатки, пишет "Не найдена таблица Док".
Что не так с менеджером виртуальных таблиц?????????
-
во втором запросе
Не исправлял, чтобы протестировать. Так попробую догадаться. Ключевую фразу процитировал.
Запрос именно второй, потому что перед текстом такой код
Запрос = Новый Запрос;
Поэтому объявленный в первом запросе менеджер не работает, ну и таблицы Док тут уже нет.
-
точно. спасибо
-
кто нибудь знает в чем отличие БлокироватьДляИзменения и БлокировкаДанных?
1)В первом случае блокируется весь регистр, во втором только те поля которые указали?
2)Почему при новой методике не используют БлокировкаДанных вместо БлокироватьДляИзменения?
3)почему в новой методике для очистки движений вместо Движения.КокойТоРегистр.Записать() используют Движения.КокойТоРегистр.Очистить()?
-
никто не знает? копаться чет нехочется
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Подтверждаю. Попалась эта задача. При сдаче экзаменатор явно сказал, что Фиксированная сумма должна быть именно в ДН
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Подтверждаю. Попалась эта задача. При сдаче экзаменатор явно сказал, что Фиксированная сумма должна быть именно в ДН
а как тогда дни считать отработанные для отпуска, он не сказал?
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Подтверждаю. Попалась эта задача. При сдаче экзаменатор явно сказал, что Фиксированная сумма должна быть именно в ДН
а как тогда дни считать отработанные для отпуска, он не сказал?
Нет, при сдаче как то не пришло в голову это спрашивать, т.к у меня было сделано, "по правильному" - в ДН. А чтобы посчитать дни, я завел еще один вид расчета с периодом действия, помимо тех которые нужно было реализовать по заданию, но как то криво это.... И сейчас даже не понимаю как же нужно делать эту задачу..
-
Начал решать 6 билет. Подскажите с условиями, пока на словах
1) В ОУ в документе "реализация" продаем комплект, т.к. остатки в регистре хранится комплектующие, то при продаже 1 комплекта списывается несколько комплектующих. Например продается 1 стул(ножка- 4 шт, спинка- 1шт, фанера -1шт)
2) В БУ в документе "реализация", если продадим 1 стул, то не получится продать комплект в БУ, т.к. закупку делали в комплектующих. т.е. можно продать комплектующие (ножка, спинка, фанера), но не стул
3) В сложных расчетах есть такое условие "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц". для суммы оплат пассажирам за прошлый месяц нужно создать отдельный документ с оборотным регистром для сумм оплаты?
-
Начал решать 6 билет. Подскажите с условиями, пока на словах
1) В ОУ в документе "реализация" продаем комплект, т.к. остатки в регистре хранится комплектующие, то при продаже 1 комплекта списывается несколько комплектующих. Например продается 1 стул(ножка- 4 шт, спинка- 1шт, фанера -1шт)
2) В БУ в документе "реализация", если продадим 1 стул, то не получится продать комплект в БУ, т.к. закупку делали в комплектующих. т.е. можно продать комплектующие (ножка, спинка, фанера), но не стул
3) В сложных расчетах есть такое условие "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц". для суммы оплат пассажирам за прошлый месяц нужно создать отдельный документ с оборотным регистром для сумм оплаты?
По поводу 3). Да надо создавать отдельный док и записывать суммы в оборотный регистр
-
Начал решать 6 билет. Подскажите с условиями, пока на словах
1) В ОУ в документе "реализация" продаем комплект, т.к. остатки в регистре хранится комплектующие, то при продаже 1 комплекта списывается несколько комплектующих. Например продается 1 стул(ножка- 4 шт, спинка- 1шт, фанера -1шт)
2) В БУ в документе "реализация", если продадим 1 стул, то не получится продать комплект в БУ, т.к. закупку делали в комплектующих. т.е. можно продать комплектующие (ножка, спинка, фанера), но не стул
3) В сложных расчетах есть такое условие "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц". для суммы оплат пассажирам за прошлый месяц нужно создать отдельный документ с оборотным регистром для сумм оплаты?
Но вы же и в ОУ списываете не комплекты, а комплектующие, точно также и для БУ делаете, получаете в запросе комплектующие из РС СоставКомплектов, и также списываете
А насчет СПР в этом билете идет немного другая постановка задачи: сумму оплат нужно получать по данным бухгалтерского учета + добавлен отчет по перерасчетам, в который должны попадать данные также при изменении этой самой суммы оплат! Советую продумать вариант решения исходя из этих условий! Т.к. по отзывам она попадается на сдаче именно в таком варианте. Я на экзамене делала так: документ Оплата пассажиров делал проводки в РБ по заданным в условии задачи счетам и в процедуре ПередЗаписью проверяла есть ли у нас в РР ДопНачисления уже записи по Надбавкам за нужный нам период, если есть то программно формировала набор записей в таблицы перерасчета РР ДопНачисления. Не знаю насколько верно такое решение, находила где-то здесь на форуме. Как узнаю результаты сдачи, отпишусь верно ли было так делать.
-
Начал решать 6 билет. Подскажите с условиями, пока на словах
1) В ОУ в документе "реализация" продаем комплект, т.к. остатки в регистре хранится комплектующие, то при продаже 1 комплекта списывается несколько комплектующих. Например продается 1 стул(ножка- 4 шт, спинка- 1шт, фанера -1шт)
2) В БУ в документе "реализация", если продадим 1 стул, то не получится продать комплект в БУ, т.к. закупку делали в комплектующих. т.е. можно продать комплектующие (ножка, спинка, фанера), но не стул
3) В сложных расчетах есть такое условие "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц". для суммы оплат пассажирам за прошлый месяц нужно создать отдельный документ с оборотным регистром для сумм оплаты?
Но вы же и в ОУ списываете не комплекты, а комплектующие, точно также и для БУ делаете, получаете в запросе комплектующие из РС СоставКомплектов, и также списываете
А насчет СПР в этом билете идет немного другая постановка задачи: сумму оплат нужно получать по данным бухгалтерского учета + добавлен отчет по перерасчетам, в который должны попадать данные также при изменении этой самой суммы оплат! Советую продумать вариант решения исходя из этих условий! Т.к. по отзывам она попадается на сдаче именно в таком варианте. Я на экзамене делала так: документ Оплата пассажиров делал проводки в РБ по заданным в условии задачи счетам и в процедуре ПередЗаписью проверяла есть ли у нас в РР ДопНачисления уже записи по Надбавкам за нужный нам период, если есть то программно формировала набор записей в таблицы перерасчета РР ДопНачисления. Не знаю насколько верно такое решение, находила где-то здесь на форуме. Как узнаю результаты сдачи, отпишусь верно ли было так делать.
По поводу СПР: насколько мне известно на данный момент есть задачки с Оплатами пассажиров как по бух учету так и по оборотному регистру. Т.е. может попасться либо 1й либо 2й тип задач.
-
Выкладываю СПР 6 с последними изменениями. Во вложении
[вложение удалено администратором]
-
На экзамене засунул фиксированный оклад в основные начисления. Экзаменатор посчитал это грубой ошибкой
Подтверждаю. Попалась эта задача. При сдаче экзаменатор явно сказал, что Фиксированная сумма должна быть именно в ДН
Вчера был на дистанционном экзамене. Все три задачи, попались из 6 билета.
В СПР, было условие, примерно следующее: Оклад - это фиксированная сумма. Она возможно и должна быть ДН, но есть но "но", для расчета отпуска, нужно знать сколько дней отработал сотрудник в предыдущих месяцах. А откуда еще взять сколько дней отработал сотрудник?
Или в ДН сделать период действия и делать все тоже самое?
-
Прикрепляю задачу СПР из 6 билета. Прошу посмотреть и помочь разобраться.
Сделал для начала в одном регистре расчета, для того что бы хотя понять логику.
1) Оклад должен быть ДопНачислением, хоть у меня и один регистр, его в любом случае делаю ОсновнымНачислением. Хоть и фиксированная цена, должна быть записана в ДН. В ОС нужно, для того чтобы записать в оборотный регистр накопления "Отработано дней", - количество отработанных дней, для дальнейшего расчета с окладом.
Базовый период оставляю пустым
2)Надбавка, тут вопросов у меня не возникло. Заменил что бы сумму бралась не из бухгалтерского регистра, а оборотного. И от этой суммы вычислялся процент.
В измерение регистра ОС "Автомобиль", будет заполняется с пустой ссылкой на автомобиль.
3)Отпуск, в любом случае он будет ОН. Берется база за три предыдущих месяца.
В измерение регистра ОС "Автомобиль", будет заполняется с пустой ссылкой на автомобиль.
Данные графика заполняются в разрезе Автомобиля и Графика
Для отпусков и начислений, надо заполнить График, а поле Автомобиль, оставить пустой ссылкой
Например, для Отпуска
График: пятидневка
Автомобиль: жигули
Для расчета надбавки или отпуска, обработку запустить с такими параметрами
График: пятидневка
Автомобиль: - (пустая )
Механизм перерасчетов не настроить, думаю понятно почему. Перерасчеты работают в одном периоде (месяце), а в начислениях, база берется из других периодов.
Мне не понятна строчка, что она значит: "считать что после расчета сумма оплат корректировки не подлежит"
-
билет № 6) Прямая запись в таблицы перерасчета при проведении по регистру бухгалтерии
////Это что и как?
-
билет № 6) Прямая запись в таблицы перерасчета при проведении по регистру бухгалтерии
////Это что и как?
Не сразу твой вопрос понял? Думаю ты интересуешься тем же вопросом, что и я? А именно можно ли реализовать перерасчет в этой задаче?
Мое личное мнение, что нельзя в рамках задачи по платформе. Почему: Перерасчеты должны быть, если меняется сумма база в регистре расчета. Для надбавки, сумма базы, - берется из регистра бухгалтерии. Уже противоречие.
Возможное решение, но это точно не правильно: записать сумму базу не в Измерение, не в Ресурс, а в Реквизит. А в отчете для проверки, нужно ли делать перерасчет, надо сравнивать сумму базу с реквизита со суммой, по бухгалтерскому учету. А это точно не то.
Прошу прокомментируйте мой ответ)
-
Комментарий тут простой - Книга проф разработка раздел по расчетам + методичка от учебного центра по решению расчетных задач. Просто смотря решенные задачи без теории ты только времени больше потеряешь думая почему и зачем так сделано.
-
методичка от учебного центра по решению расчетных задач.
А Вы не могли бы отсканировать методичку по росчетным задачам? это было бы так по товарищески с вашей стороны :)))
-
Таблица перерасчетов содержит данные о тех записях, которые возможно требуется пересчитать. Давай разбираться дальше.
Перерасчеты должны быть, если меняется сумма база в регистре расчета.
Так работают автоматически помещаемые системой в таблицу перерасчетов записи. То есть когда мы указываемые зависимые виды расчета, система видит что изменился ведущий вид расчета, зависимый необходимо пересчитать, система САМА добавляет эти записи в таблицу перерасчетов.
Для надбавки, сумма базы, - берется из регистра бухгалтерии. Уже противоречие.
В этом случае система по понятным причинам ничего САМА не запишет в таблицу перерасчетов. В этом случае необходимо осуществлять ПРОГРАММНУЮ запись в таблицу перерасчетов. В модуле набора записей регистра бухгалтерии анализировать текущие проводки и при необходимости программно писать данные в таблицу перерасчетов.
Здесь можно посмотреть рабочий код от Гакусея, там же мы с ним обсуждали эту задачку:
http://forum.chistov.pro/index.php?topic=993.msg47196#msg47196
-
А Вы не могли бы отсканировать методичку по росчетным задачам? это было бы так по товарищески с вашей стороны :)))
Рискуете вы и меня под монастырь подводите ;D. Самый большой грех на этом форуме - попрошайничество материалов с авторскими правами. Сотрите пока никто не заметил ;D
-
А Вы не могли бы отсканировать методичку по росчетным задачам? это было бы так по товарищески с вашей стороны :)))
Рискуете вы и меня под монастырь подводите ;D. Самый большой грех на этом форуме - попрошайничество материалов с авторскими правами. Сотрите пока никто не заметил ;D
Внимательно слежу за развитием событий ;)
-
Таблица перерасчетов содержит данные о тех записях, которые возможно требуется пересчитать. Давай разбираться дальше.
Перерасчеты должны быть, если меняется сумма база в регистре расчета.
Так работают автоматически помещаемые системой в таблицу перерасчетов записи. То есть когда мы указываемые зависимые виды расчета, система видит что изменился ведущий вид расчета, зависимый необходимо пересчитать, система САМА добавляет эти записи в таблицу перерасчетов.
Для надбавки, сумма базы, - берется из регистра бухгалтерии. Уже противоречие.
В этом случае система по понятным причинам ничего САМА не запишет в таблицу перерасчетов. В этом случае необходимо осуществлять ПРОГРАММНУЮ запись в таблицу перерасчетов. В модуле набора записей регистра бухгалтерии анализировать текущие проводки и при необходимости программно писать данные в таблицу перерасчетов.
Здесь можно посмотреть рабочий код от Гакусея, там же мы с ним обсуждали эту задачку:
http://forum.chistov.pro/index.php?topic=993.msg47196#msg47196
В этой ветки, есть запрос, не уверен что он правильно. Есть ли ветка, где разбирали примеры в самой конфигурации, а не в виде текста. Хочется посмотреть на реальные примеры. А так пока не понятно.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| ТЧ.СубконтоКт1 КАК Сотрудник,
| НАЧАЛОПЕРИОДА(ТЧ.Период, МЕСЯЦ) КАК Период
|ПОМЕСТИТЬ ВТ
|ИЗ
| &ТЧ КАК ТЧ
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ОсновныеНачисления.Регистратор,
| ОсновныеНачисления.Сотрудник,
| ОсновныеНачисления.ВидРасчета
|ПОМЕСТИТЬ РР
|ИЗ
| РегистрРасчета.ОсновныеНачисления КАК ОсновныеНачисления
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ КАК ВТ
| ПО ОсновныеНачисления.Сотрудник = ВТ.Сотрудник
|ГДЕ
| ОсновныеНачисления.ВидРасчета = &ВидРасчета
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| РР.Регистратор КАК Регистратор,
| РР.Сотрудник,
| РР.ВидРасчета
|ИЗ
| РР КАК РР
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрРасчета.ОсновныеНачисления.Перерасчет1 КАК Перерасчет1
| ПО РР.Регистратор = Перерасчет1.ОбъектПерерасчета
| И РР.Сотрудник = Перерасчет1.Сотрудник
| И РР.ВидРасчета = Перерасчет1.ВидРасчета
|ГДЕ
| Перерасчет1.ОбъектПерерасчета ЕСТЬ NULL
|
|УПОРЯДОЧИТЬ ПО
| Регистратор
|ИТОГИ ПО
| Регистратор";
Запрос.УстановитьПараметр("ТЧ",ЭтотОбъект.Выгрузить());
Запрос.УстановитьПараметр("ВидРасчета",ПланыВидовРасчета.ОсновныеНачисления.БУух);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаРегистратор = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаРегистратор.Следующий() Цикл
Запись=РегистрыРасчета.ОсновныеНачисления.Перерасчеты.Перерасчет1.СоздатьНаборЗаписей();
Запись.Отбор.ОбъектПерерасчета.Значение=ВыборкаРегистратор.Регистратор;
Выборка=ВыборкаРегистратор.Выбрать();
Пока Выборка.Следующий() Цикл
// Вставить обработку выборки ВыборкаДетальныеЗаписи
стр=Запись.Добавить();
стр.ВидРасчета=Выборка.ВидРасчета;
стр.Сотрудник=Выборка.Сотрудник;
КонецЦикла;
Запись.Записать(Ложь);
КонецЦикла;
-
Пользуясь случаем задам методический вопрос Павлу Чистову.
После прорешивания расчетных задач один момент для меня остался непонятным, в выложенных решениях тоже кто как это реализует.
Это определение средней дневной (или часовой) ставки при расчете среднего заработка, когда в задаче сказано, что ставка определяется исходя из "рабочих дней". Рабочие дни как известно это плановые дни по графику, а какой график тут грамотно применить - тот по которому работник работал в тот период или график отпуска/командировки?
Логично применить тот график, по которому работник работал тот период, но тут во-первых проблема определить рабочие (не отработанные) дни, если график менялся в течении месяца базового периода, а во-вторых если работник работал допустим сутки через трое, а в командировке на пятидневке, корректно ли ему платить среднедневную исходя из того графика?
С другой стороны по пятидневке определять рабочие дни в прошлом периоде тоже не корректно, ведь он работал по другому графику (и возможно что еще график менялся в течение базового периода).
Также встречается условие (задача 9), что период больничного по календарным дням, а среднедневное по рабочим дням, что в принципе не корректно.
Сам вопрос возник от того, что условие задачи расчета среднего(это 6, 7, 9) отличается от реального расчета среднего на предприятиях, как посоветуете методически грамотно поступить в данном случае?
-
Добрый день.
Хотелось бы узнать, кто как реализовал условие "Сотрудники работают на автомобилях предприятия, поэтому возможен обмен автомобилями между водителями". Вопрос: делать автомобиль реквизитом или измерением? Мне кажется что измерением, потому что возможна разная комбинация сотрудник-автомобиль. Но в некоторых решениях скачанных с форума, решено иначе.
Вообще меня этот билет в ступор загнал если честно:"Обратите внимание, в отчете также должна отражаться информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров". И следом: "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется".
-
Вообще меня этот билет в ступор загнал если честно:"Обратите внимание, в отчете также должна отражаться информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров". И следом: "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется".
Это значит, что в отчете нужно вывести те документы, которые необходимо перерасчитать. Но сам механизм перерасчетов реализовывать не нужно
-
Вообще меня этот билет в ступор загнал если честно:"Обратите внимание, в отчете также должна отражаться информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров". И следом: "Саму процедуру перерасчета записей в рамках данной задачи реализовывать не требуется".
Это значит, что в отчете нужно вывести те документы, которые необходимо перерасчитать. Но сам механизм перерасчетов реализовывать не нужно
Спасибо за ответ. Хотелось бы еще узнать мнение участников форума по поводу измерения/реквизита автомобиль РР.
-
Хотелось бы еще узнать мнение участников форума по поводу измерения/реквизита автомобиль РР.
Вот здесь
http://forum.chistov.pro/index.php?topic=993.msg41978#msg41978
И это не мнение, а верный ответ.
-
Хотелось бы еще узнать мнение участников форума по поводу измерения/реквизита автомобиль РР.
Вот здесь
http://forum.chistov.pro/index.php?topic=993.msg41978#msg41978
И это не мнение, а верный ответ.
Спасибо.
-
Добрый день!
Готовлюсь к сдаче на специалиста.
В решении билета в части БУ для списания копеек получилось очень много условий.
Можно ли как-то их уменьшить? Уже голову сломал.
Спасибо!
-
Добрый день!
Готовлюсь к сдаче на специалиста.
В решении билета в части БУ для списания копеек получилось очень много условий.
Можно ли как-то их уменьшить? Уже голову сломал.
Спасибо!
По-моему, просто при вычислении себестоимости нужно сначала умножать, а затем делить, и всё!
Например:
Себестоимость=КоличествоСписываем*СуммаОстаток/КоличествоОстаток;Так при списывании оставшихся 3 шт на сумму 33,34 руб, спишется все 3 шт на ВСЕ 33,34 руб. (а не 33,33), т.е. Себестоимость=33,34 руб.
А если сначала делить затем умножать:
Цена=СуммаОстаток/КоличествоОстаток; (=11,11 руб.)
Себестоимость=Цена*КоличествоСписываем; (=33,33 руб.)Преславутая копейка останется не списанной.
Мне не понятно почему вы в запросе в модуле объекта документа "Расходная накладная" выбираете по сути одни и те же данные 3 раза? (во вложениях изображения)
неужели не получилось двумя запросами(выбрать даные документа и к нему уже остатки партий по складу)?
ведь в условии сказано:"Себестоимость товара рассчитывается в разрезе партий поступления этого товара" - то есть себестоимость рассчитывать для каждой партии отдельно, а не по складу в целом(если вы так думали).
Также не уверен, что правильно в цикле перебирая всю номенклатуру документа устанавливать блокировки:
Блокировка = Новый БлокировкаДанных;
Пока Выборка.Следующий() Цикл
ЭлементБлокировки = Блокировка.Добавить("РегистрБухгалтерии.Управленческий");
ЭлементБлокировки.УстановитьЗначение("Период", Новый Диапазон(, Дата));
ЭлементБлокировки.УстановитьЗначение("Счет", ПланыСчетов.Управленческий.Товары);
ЭлементБлокировки.УстановитьЗначение(ПланыВидовХарактеристик.ВидыСубконто.Склад, Склад);
ЭлементБлокировки.УстановитьЗначение(ПланыВидовХарактеристик.ВидыСубконто.Номенклатура, Выборка.Номенклатура);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
КонецЦикла;
можно было как делают многие:
Блок=Новый БлокировкаДанных;
лЭлБлок=Блок.Добавить("РегистрБухгалтерии.Управленческий");
лЭлБлок.ИсточникДанных=СписокНоменклатуры;
лЭлБлок.ИспользоватьИзИсточникаДанных(ПланыВидовХарактеристик.ВидыСубконто.Номенклатура,"Номенклатура");
лЭлБлок.УстановитьЗначение(ПланыВидовХарактеристик.ВидыСубконто.Склад,Склад);
лЭлБлок.УстановитьЗначение("Счет",ПланыСчетов.Управленческий.Товары);
лЭлБлок.Режим=РежимБлокировкиДанных.Исключительный;
Блок.Заблокировать();
А сам цикл списания партий не стал разбирать :(
-
моё решение.
Жду критики.
:)
-
По-моему, просто при вычислении себестоимости нужно сначала умножать, а затем делить, и всё!
За это снимут балл. Не спрашивайте почему, сам не могу понять уже много лет. Просто предупредил.
-
может снимают у тех кто неправильно формулу написал, т.е. например в задачах, где 2 субконто Номенклатура и Партия, а с/сть считается только по Номенклатуре. Можно ДвижениеКоличество*СуммаИтог/КолОстИтог (тогда не закроются копейки), а можно ДвижениеКоличество*ОстатокСуммаИтог/ОстатокКолОстИтог (внизу уменьшать ОстатокСуммаИтог и ОстатокКолОстИтог)(Тогда закроются).
По-моему, просто при вычислении себестоимости нужно сначала умножать, а затем делить, и всё!
За это снимут балл. Не спрашивайте почему, сам не могу понять уже много лет. Просто предупредил.
-
Мне не понятно почему вы в запросе в модуле объекта документа "Расходная накладная" выбираете по сути одни и те же данные 3 раза? (во вложениях изображения)
неужели не получилось двумя запросами(выбрать даные документа и к нему уже остатки партий по складу)?
ведь в условии сказано:"Себестоимость товара рассчитывается в разрезе партий поступления этого товара" - то есть себестоимость рассчитывать для каждой партии отдельно, а не по складу в целом(если вы так думали).
Я опирался на условие что если номенклатура по одной приходной поступит на разные склады по разной стоимости. Например 10 шт по 10 руб на Склад1 и 10 шт по 12 руб на Склад2. В вашем варианте решения Вы с первого склада будете списывать по 10 рублей, в то время как себестоимость партии 11 рублей.
По расчету себестоимости брал формулу из методички.
Блокировку делал тоже как в методичке.
По вашему решению билет БУ6:
Блокировку накладываете по данным табличной части полученным в объектной модели доступа. Говорят что нужно эти данные получать запросом из базы данных. Тем более, что далее вы их получаете запросом.
-
Блокировку накладываете по данным табличной части полученным в объектной модели доступа. Говорят что нужно эти данные получать запросом из базы данных. Тем более, что далее вы их получаете запросом.
На экзамене не бывает проблем из-за получения данных для блокировки из ТЧ документа.
-
моё решение.
Жду критики.
:)
В части БУ вы списываете не по стоимости партии. У вас на складе стоимость поступающего товара из табличной части, а она может быть не равна себестоимости партии(как я думаю и писал об этом выше).
По СПР. У вас оклад в основных начислениях. Так как по условию это фиксированная сумма в месяц, то он мог бы вполне относится к дополнительным, как не имеющий период действия.
Надбавку же наоборот я бы отнес к основным начислениям. Для примера работник Иванов отъездил на машине №45 в период с 1 по 12 октября и сдал выручку в размере 10000 рублей, за этот период ему полагается надбавка в виде процента от сданной выручки.
Измерением графика можно было бы сделать автомобиль для расчета количества отработанных дней для расчета отпуска.
Возможно я где-то не прав, сам только учусь.
-
1:
Я опирался на условие что если номенклатура по одной приходной поступит на разные склады по разной стоимости. Например 10 шт по 10 руб на Склад1 и 10 шт по 12 руб на Склад2. В вашем варианте решения Вы с первого склада будете списывать по 10 рублей, в то время как себестоимость партии 11 рублей.
В части БУ вы списываете не по стоимости партии. У вас на складе стоимость поступающего товара из табличной части, а она может быть не равна себестоимости партии(как я думаю и писал об этом выше).
2:
По СПР. У вас оклад в основных начислениях. Так как по условию это фиксированная сумма в месяц, то он мог бы вполне относится к дополнительным, как не имеющий период действия.
3:
Надбавку же наоборот я бы отнес к основным начислениям. Для примера работник Иванов отъездил на машине №45 в период с 1 по 12 октября и сдал выручку в размере 10000 рублей, за этот период ему полагается надбавка в виде процента от сданной выручки.
4:
Измерением графика можно было бы сделать автомобиль для расчета количества отработанных дней для расчета отпуска.
Возможно я где-то не прав, сам только учусь.
1: Увидел, да, моё решение от 18 октября не верное в части БУ, исправил.
2: Оклад разве не вытесняется отпуском? В условии не сказано об этом, если не вытесняется, то, да, можно в допначисления.
3: Из условия:"Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент." - то есть всегда за прошлый месяц.
4: Я график сделал реквизитом справочника Автомобили.
Исправленное решение прилагаю.
-
По-моему, просто при вычислении себестоимости нужно сначала умножать, а затем делить, и всё!
За это снимут балл. Не спрашивайте почему, сам не могу понять уже много лет. Просто предупредил.
Спасибо!
Вопрос, за такую формулу не снимут балл:
Себестоимость=?(Списываем=КоличествоОстаток, СуммаОстаток, Списываем*СуммаОстаток/КоличествоОстаток);
-
Вопрос, за такую формулу не снимут балл:
Себестоимость=?(Списываем=КоличествоОстаток, СуммаОстаток, Списываем*СуммаОстаток/КоличествоОстаток);
Нет
-
Коллеги, приветствую!
Охох, вернулся к подготовке к спецу и опять затор на задаче из БУ.
Условие "Себестоимость товара рассчитывается в разрезе партий поступления этого товара".
Если трактовать как "Себестоимость товара рассчитывается в разрезе партий поступления этого товара на выбранный в шапке склад", то вроде как задача банальная - просто по ФИФО\ЛИФО списываем партии, поступавшие на склад в шапке.
Если трактовать как "Себестоимость товара рассчитывается в разрезе партий поступления этого товара независимо от склада (т.е. на любой склад)", то задача заметно усложняется. Но тогда условие какое-то нелепое: вроде учет партионный, а себес берем средний по всем партиям.
Почитав ветку, однозначной интерпретации, как я понял, нет.
Есть все-таки люди, сдававшие успешно экзамен с этой задачей?
Великий Павел, может Вы подключитесь? :)
-
Если трактовать как "Себестоимость товара рассчитывается в разрезе партий поступления этого товара независимо от склада (т.е. на любой склад)", то задача заметно усложняется. Но тогда условие какое-то нелепое: вроде учет партионный, а себес берем средний по всем партиям.
Именно так и трактуется условие списания себестоимости в этой задаче. Сложности здесь нет, если для плана счетов правильно использовать признаки учета субконто.
-
Ahang, не могли бы Вы выложить Ваш вариант решения, пожалуйста?
-
Ahang, не могли бы Вы выложить Ваш вариант решения, пожалуйста?
Пожалуйста
-
ahang, я бы решил так же;
может я чего-то не до конца понимаю, но в таком случае произойдет следующее:
1. Приход №1 --- Товар1 --- Склад2 --- 10шт --- 1000 руб.
2. Приход №2 --- Товар1 --- Склад1 --- 10шт --- 2000 руб.
3. Расход №1 --- Товар1 --- Склад1 --- 10шт --- 5000 руб. (условная сумма продажи, сейчас не важно какая)
Товар на складе1 для проведения есть? Есть. Следовательно, документ отгрузки проведется.
НО, в Вашем решении произойдет следующее:
1 партия по моменту времени это Приход №1, но товар там приходил на склад2, а не склад1 в шапке расходной накладной
После проведения остаток количественный в разрезе "Номенклатура-Склад-Партия" будет такой:
Товар1 --- Склад1 --- Приход №1 --- (-10)шт (он ведь не приходовался ранее на склад1)
Товар1 --- Склад2 --- Приход №2 --- 10шт (его не списывали)
Товар1 --- Склад2 --- Приход №1 --- 10шт (мы так его и не списали в таком разрезе)
Регистр не сходится в "ноль" по всем субконто. Что скажете?
-
Регистр не сходится в "ноль" по всем субконто. Что скажете?
Я скажу, что Вы чертовски правы! ... и как же я об этом не подумал )) Ну а если к делу, то в этом случае у меня приходит на ум добавить еще:
1) два количественных признака учета субконто (Количественный - для подсчета товара на складе и КоличественныйПартия - для подсчета товара в партии);
2) ресурс КоличествоПартии.
Конечно не забываем для ресурсов регистра сделать правильные привязки, а также настроить счет "Товары".
Тогда должно все списываться верно!
Доработанную базу прилагаю ))
-
Резюмируя и консолидируя информацию в ветке, решение получается следующее:
(Названия ресурсов и признаков учета индивидуальны)
Мы добавляем 1 ПУ: "Количественный" и 3 ПУС: "Суммовой", "Количественный", "КоличественныйПартия".
В РБ 3 ресурса:
- "КоличествоСклад" (связан с ПУ и ПУС "Количественный")
- "КоличествоПартия" (связан с ПУ и ПУС "КоличественныйПартия")
- "Сумма" (связан с ПУС "Суммовой")
ПУ ставим только на счете "Товары".
ПУС "Суммовой" нужен для того, чтобы НЕ вести суммовой учет на складах (иначе будут минусы по СуммаОстаток при списании из партии, поступившей на другой склад).
ПУС "Количественный" нужен для того, чтобы вести учет ресурса "КоличествоСклад" только по номенклатуре и складу (у партии убираем).
ПУС "КоличественныйПартия" нужен для того, чтобы вести учет ресурса "КоличествоПартия" только по номенклатуре и партии (у склада убираем).
Разделяя количественный ресурс РБ на 2, мы гарантируем, что регистр будет сводиться в ноль при любых условиях.
Далее классическое партионное списание по FIFO\LIFO.
-
Резюмируя и консолидируя информацию в ветке, решение получается следующее:
(Названия ресурсов и признаков учета индивидуальны)
Мы добавляем 1 ПУ: "Количественный" и 3 ПУС: "Суммовой", "Количественный", "КоличественныйПартия".
В РБ 3 ресурса:
- "КоличествоСклад" (связан с ПУ и ПУС "Количественный")
- "КоличествоПартия" (связан с ПУ и ПУС "КоличественныйПартия")
- "Сумма" (связан с ПУС "Суммовой")
ПУ ставим только на счете "Товары".
ПУС "Суммовой" нужен для того, чтобы НЕ вести суммовой учет на складах (иначе будут минусы по СуммаОстаток при списании из партии, поступившей на другой склад).
ПУС "Количественный" нужен для того, чтобы вести учет ресурса "КоличествоСклад" только по номенклатуре и складу (у партии убираем).
ПУС "КоличественныйПартия" нужен для того, чтобы вести учет ресурса "КоличествоПартия" только по номенклатуре и партии (у склада убираем).
Разделяя количественный ресурс РБ на 2, мы гарантируем, что регистр будет сводиться в ноль при любых условиях.
Далее классическое партионное списание по FIFO\LIFO.
Aluvika, все верно! У меня еще была мысль попробовать разделить товарный учет на субсчета (первый для ведения аналитик по Номенклатуре и Складу, второй - для аналитик Номенклатура, Партия). Но по моему этот вариант хуже, хотя (скорее всего) имеет место быть.
-
Мутноватая тема с дополнительным ресурсом, который добавляется ради одной операции на одном счете.
Во всех внутренних таблицах итогов теперь добавится дополнительная колонка и в интерфейсе во всех проводках будет светиться этот ресурс непонятного назначения.
Плюс 3 пуса еще надо, как-то некрасиво получается.
Можно просто добавить забалансовый счет ТоварыНаСкладах для хранения количества по номенклатуре и складу.
На счете Товары все будет по классике - Номенклатура, Партии, Количество, Сумма. Пусов не надо ни одного.
В типовой бухгалтерии тоже на забалансовых счетах всякая хрень хранится и по-моему тоже она проверяется при проведении.
Тут в комментариях было, что препод на экзамене говорил, что на 1 ресурсе оптимальнее делать. Я чую, что это этот варииант и есть.
Есть кто смелый проверить мой вариант на экзамене? ;D
-
Обновленное моё решение.
Жду критики.
-
А мне объяснили по поводу не выхода РБ в ноль так:
"РБ - не обязан выходить в ноль, так как у нас есть документ "Операция", с помощью которого можно ввести проводку, выводящую РБ в ноль при необходимости!"
Если же объяснять "по-научному": ;) Бухгалтерия вообще не предполагает вывод РБ в ноль из-за своей специфики учета, остатки в ней есть всегда! И переносятся на следующий учетный период. Отсюда вывод: все заморочки с количественными признаками заведомо неверный подход для бухучета, поэтому на экзамене стали обращать на эти выкрутасы с количественными ресурсами :o ...и снижать баллы! :(
Поэтому следует быть осторожнее с количественными признаками - лучше использовать ПУС и количественный признак для одного количественного ресурса! ИМХО так правильнее будет, и не стоит заморачиваться в БУ о выводе остатка в ноль - это актуально только для ОУ. :D
-
Видимо в этой задачи признаки учета субконто не нужны в принципе.
Я на экзамене делала по схеме 3 ПУС + 2 ресурса для количества, решение не приняли.
Заведено 3 ненужных признака учета субконто. При этом нет признака учета "Количественный". Определено 2 количественных ресурса.
Вот тут в "Результатах сдачи" ещё девушка писала, что у неё такое решение не приняли (ник dei199)
http://forum.chistov.pro/index.php?topic=993.3225
-
Ещё туда же:
Себестоимость и количество в системе должно хранится с аналитикой:
- Номенклатура
- Склад
- Партия
О том, что количественный и стоимостной учет ведется в разных аналитиках в условии задачи ничего сказано не было.
Не нужно было использовать признаки учета субконто
-
А мне объяснили по поводу не выхода РБ в ноль так:
"РБ - не обязан выходить в ноль, так как у нас есть документ "Операция", с помощью которого можно ввести проводку, выводящую РБ в ноль при необходимости!"
Мне кажется, тот кто объяснял, не понял, что подразумевается под выводом регистра в ноль.
Кстати, и в перечне ошибок формулировка несколько отличная от той, что написали вы: "Построенная в решении учетная схема принципиально не позволяет одновременно вы-вести в ноль все ресурсы регистра накапливающего информацию об остатках". Имеется ввиду, что, например, при определенных условиях количество и сумма одновременно становятся равны нулю. Банальная ситуация, и никакой разницы, ОУ это или БУ.
-
alex1248 насчет остатков ты прав, вообще-то я стараюсь эту ошибку учитывать при решениях билетов, выразилась выше не совсем правильно с точки зрения платформы, хотя в прикладных задачах по БУ остатки часто бывают, и редко выходят в ноль. :D
В билете условие расчета себестоимости такое:
"Себестоимость товара рассчитывается в разерезе партий поступления этого товара" т. е. без складов: Долго думала как делать настройки РБ - получилось так (см. скриншот):
Если учитывать, что РБ - по сути регистр регистров, то остатки нормально выводятся в ноль (насколько понимаю в ОУ нужно сихронизирование движений по нескольким РН, в РБ - не нужна сихронизация движений), а так ресурсов РБ - у меня два количество и сумма.
Как правильно - хз, скоро снова сдаваться, а вот в 6 билете по ОУ и БУ нет полной уверенности в правильности решения. :-[
Кстати, насчет этих дурацких стелажей в ОУ, никак не пойму как правильно делать проверку в РС на уникальность записей, так как здесь говорят, что РС с измерением "Деталь" и ресурсом "Стелаж" - заведомо неправильное решение. Что-то я никак не соображу как делать проверку на уникальность записей в РС, что не удивительно без опыта-то... :o
-
Ещё туда же:
Себестоимость и количество в системе должно хранится с аналитикой:
- Номенклатура
- Склад
- Партия
О том, что количественный и стоимостной учет ведется в разных аналитиках в условии задачи ничего сказано не было.
Не нужно было использовать признаки учета субконто
Если не было на экзамене этой фразы в условии задачи: "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" тогда, да, ПУС не нужен! На экзамене надо очень внимательно читать условие задачи, заведомо ведь известно, что экзаменаторы могут менять условия задачи.
А аналитика, да одинаковая должна быть - как у вас получилась разная? :o
-
Мне тут в голову пришло вот что: Народ тут заморачивается с количествами по поводу не выхода РБ в ноль, но почему-то многие забывают, что субконто РБ по своей сути - это характеристики! То бишь ПВХ в ОУ - с ними-то (ПВХ) ведь в ОУ не заморачивается никто! :D А в БУ действуют так, как будто работают с измерениями регистра. ;D
-
Мне тут в голову пришло вот что: Народ тут заморачивается с количествами по поводу не выхода РБ в ноль, но почему-то многие забывают, что субконто РБ по своей сути - это характеристики! То бишь ПВХ в ОУ - с ними-то (ПВХ) ведь в ОУ не заморачивается никто! :D А в БУ действуют так, как будто работают с измерениями регистра. ;D
;D ;D
-
билет 6
-
"Себестоимость товара рассчитывается в разерезе партий поступления этого товара" т. е. без складов:
Кстати, насчет этих дурацких стелажей в ОУ, никак не пойму как правильно делать проверку в РС на уникальность записей, так как здесь говорят, что РС с измерением "Деталь" и ресурсом "Стелаж" - заведомо неправильное решение.
Думаю, себестоимость следует рассчитывать-таки с учетом складов, потому что формулировка неоднозначная, а 2 ресурса не приветствуются.
Стеллажи проверять, как я помню - проверять есть ли записываемая деталь в записи РС, отличной от текущей.
-
Думаю, себестоимость следует рассчитывать-таки с учетом складов, потому что формулировка неоднозначная, а 2 ресурса не приветствуются.
Стеллажи проверять, как я помню - проверять есть ли записываемая деталь в записи РС, отличной от текущей.
А как получить текущую запись? Извините, за заведомо глупый вопрос, но что-то не догоняю... :-[, хотя понятно, что имеющиеся записи в РС можно получить запросом. :)
-
Думаю, себестоимость следует рассчитывать-таки с учетом складов, потому что формулировка неоднозначная, а 2 ресурса не приветствуются.
Стеллажи проверять, как я помню - проверять есть ли записываемая деталь в записи РС, отличной от текущей.
А как получить текущую запись? Извините, за заведомо глупый вопрос, но что-то не догоняю... :-[, хотя понятно, что имеющиеся записи в РС можно получить запросом. :)
В моем последнем решении в форме записи РС такая процедура (да, получаю тоже запросом, объектную модель почти не знаю )) ).
&НаСервере
Процедура ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Запрос = новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| СоставСтеллажей.Количество
|ИЗ
| РегистрСведений.СоставСтеллажей КАК СоставСтеллажей
|ГДЕ
| СоставСтеллажей.Стеллаж <> &Стеллаж
| И СоставСтеллажей.Деталь = &Деталь";
Запрос.УстановитьПараметр("Стеллаж", Запись.Стеллаж);
Запрос.УстановитьПараметр("Деталь", Запись.Деталь);
Рез = запрос.Выполнить();
Если не рез.Пустой() Тогда
Отказ = истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "деталь уже используется";
Сообщение.Сообщить();
КонецЕсли;
Если Запись.Стеллаж.ВидНоменклатуры <> Перечисления.ВидыНоменклатуры.Стеллаж Тогда
Отказ = истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "только стеллаж может состоять из деталей";
Сообщение.Сообщить();
КонецЕсли;
Если Запись.Деталь.ВидНоменклатуры = Перечисления.ВидыНоменклатуры.Стеллаж Тогда
Отказ = истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "стеллаж не может входить в состав другого стеллажа";
Сообщение.Сообщить();
КонецЕсли;
КонецПроцедуры
P.S. На самом деле, у меня тут в запросе нет проверки на неравенство текущей записи, но если кому не нравится, за основу для доработки собственного решения, возможно, сгодится ).
PPS. А вообще, проверяется чтобы не было записи по этой же детали для другого стеллажа - так и надо. Для этого же стеллажа эту же деталь не даст записать сама система. Вроде, всё логично?
PPPS. Ага, понял, где камушек. Также будет невозможно изменить запись, заменив стеллаж на другой, т.е. непосредственно перенести деталь в другой стеллаж. Значит, юзеру придется поработать через удаление существующей записи или еще как-то иначе. Но уникальность будет соблюдена. Или желающим можно доработать этот момент ).
Кстати, вчера сам так же обходными путями правил реквизиты договора с контрагентами, которые уже задействованы в проводках в типовой БП ).
-
Спасибо большое, alex1248! Проверю код на досуге, у вас на экзамене эту проверку уникальности деталей и стелажей зачли?
-
Спасибо большое, alex1248! Проверю код на досуге, у вас на экзамене эту проверку уникальности деталей и стелажей зачли?
Мне эта задача не попадалась.
-
Мне эта задача не попадалась.
Пусть и мне лучше не попадается... :-[ Слишком объемная и сложная для меня - есть опасения не уложиться в 5 часов, хотя сейчас я решаю намного быстрее. А если еще со стелажами столько возни, то труба... И почему РС с одним измерением "Деталь" считается неверным решением? :( Хотя по логике вроде нормально одна и та же деталь не будет попадаться в других стелажах кроме одного и только в определнном количестве. :-\
-
... И почему с одним измерением "Деталь" считается неверным решением?
Выскажу лишь свое ИМХО. Всё же РС предназначен для хранения информации о количестве деталей (ресурс) в разрезе деталей и стеллажей (измерения), и получать данные о составе стеллажа (именно это - его основное назначение, а не соблюсти уникальность) эффективнее именно при такой структуре. Требование уникальности - это лишь частный случай данной задачи, и РС в этом не виноват ).
-
Хочу немного изложить свои мысли по БУ.
В регистре бухгалтерии ресурсы Сумма и Количество.
Второе количество смысла не имеет т.к. одной строкой документа поступает однозначно определенное количество
оно поступает с тремя измерениями: Номенклатура, Партия, Склад.
Заводим признак учета Количественный, чтобы вести количественный учет по счету товару.
Ресурс Количество - небалансовый.
Количественный остаток по каждому из трех измерений имеет значение.
А суммовой остаток у нас по условию имеет значение в разрезе Номенклатуры и Партии.
В разрезе Склада суммовой остаток не должен существовать,
поэтому мы заводим признак учета субконто Суммовой.
И отключаем суммовой учет в разрезе складов.
Остальное дело запросов и расчетов.
-
Хочу немного изложить свои мысли по БУ.
В регистре бухгалтерии ресурсы Сумма и Количество.
Второе количество смысла не имеет т.к. одной строкой документа поступает однозначно определенное количество
оно поступает с тремя измерениями: Номенклатура, Партия, Склад.
Заводим признак учета Количественный, чтобы вести количественный учет по счету товару.
Ресурс Количество - небалансовый.
Количественный остаток по каждому из трех измерений имеет значение.
А суммовой остаток у нас по условию имеет значение в разрезе Номенклатуры и Партии.
В разрезе Склада суммовой остаток не должен существовать,
поэтому мы заводим признак учета субконто Суммовой.
И отключаем суммовой учет в разрезе складов.
Остальное дело запросов и расчетов.
;D ;D
-
Это решение на одном ресурсе без всяких забалансовых счетов.
Реализация есть в 217 посте этой ветки.
-
Это решение на одном ресурсе без всяких забалансовых счетов.
Все такие решения имеют один недостаток, о котором тут писали 100500 раз.
Сорри, повторяться еще раз не буду.
PS. Никакие запросы и расчеты не могут помочь свести в принципе несводимую информацию.
-
Это решение на одном ресурсе без всяких забалансовых счетов.
Все такие решения имеют один недостаток, о котором тут писали 100500 раз.
Сорри, повторяться еще раз не буду.
PS. Никакие запросы и расчеты не могут помочь свести в принципе несводимую информацию.
не понимаю в чем проблема, я не получаю отрицательных остатков.
Если Вам не сложно, подскажите на каких данных я их могу получить?
Регистр в ноль выводится.
Привожу скриншот консоли запросов остатков по счету "Товары".
-
на каких данных я их могу получить?
Хм, сумму прихода пишете на пустой склад? Возможно, это именно то, что надо.
Но первый раз вижу такой вариант. Надо посмотреть и подумать. Вообще, это надо делать тем, кто еще не сдал.
-
Похоже предыдущие сообщения никто не читает ;D
Краткое содержание - если делать задачу в лоб, то нужно 2 ресурса для количества и 3 пуса. Меньше не получится.
Но хоть в этом варианте и все сходится в 0, он имеет свои недостатки, поэтому его забраковали.
Как делать нормально написано еще до забраковки основного варианта в #236 8)
Dertu, напиши проводки по 1-2 товарам, по ним мы поймем о чем этот вариант и сходится в 0 или нет.
-
Не поленился, скачал решение dertru ;D ;D
В решении не соблюдается условие задачи списание партий лифо-фифо ;D , партия в списании берется произвольно в зависимости от склада в расходной ;D, т.е. похоже что смысл задачи не понят ;D
п.с. никакой пустой склад естественно не поможет ;D если мы приходуем на пустой склад, то нужно также приходовать и на нормальный склад, для контроля остатков по складу ;D а это уже будет удвоенное количество по номенклатуре на остатках ;D
-
если мы приходуем на пустой склад, то нужно также приходовать и на нормальный склад, для контроля остатков по складу
Да, наверное, именно в этом проблема данного решения. А то я сильно удивился, почему никто не додумался раньше ).
Давно сдавал, забываю уже ).
-
Не поленился, скачал решение dertru ;D ;D
В решении не соблюдается условие задачи списание партий лифо-фифо ;D , партия в списании берется произвольно в зависимости от склада в расходной ;D, т.е. похоже что смысл задачи не понят ;D
Согласен, у нас разное понимание условия задачи. Я списываю партии по лифо-фифо, но в рамках одного склада. В условии задачи явно не указано что нужно списывать партию полностью. Понятие "Дисциплина FIFO" у всех разное.
-
Согласен, у нас разное понимание условия задачи. Я списываю партии по лифо-фифо, но в рамках одного склада. В условии задачи явно не указано что нужно списывать партию полностью. Понятие "Дисциплина FIFO" у всех разное.
ФИФО конечно разное может быть. ;D Но после него в условии задачи идет предложение "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" ;D Из чего следует, что тут ФИФО именно по партиям, а не по партии-склад, а склад только для контроля остатков ;D
Без этого предложения задача была бы простейшая, без всяких ресурсов и пусов ;D Вобщем как у тебя и получилось ;D
-
Согласен, у нас разное понимание условия задачи. Я списываю партии по лифо-фифо, но в рамках одного склада. В условии задачи явно не указано что нужно списывать партию полностью. Понятие "Дисциплина FIFO" у всех разное.
ФИФО конечно разное может быть. ;D Но после него в условии задачи идет предложение "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" ;D Из чего следует, что тут ФИФО именно по партиям, а не по партии-склад, а склад только для контроля остатков ;D
Без этого предложения задача была бы простейшая, без всяких ресурсов и пусов ;D Вобщем как у тебя и получилось ;D
Я и списываю по себестоимости партии в целом, просто я с самой партии списываю только ту часть которая лежит на складе.
-
Я и списываю по себестоимости партии в целом, просто я с самой партии списываю только ту часть которая лежит на складе.
Я понял как ты понял эту задачу ;D И в твоем понимании она вроде как нормально реализована ;D
Но в предложении "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" - сказано просто партий, про склад ни слова. ;D
Все кто сдавал, делали ФИФО просто по партиям без учета склада, и замечаний по этому поводу вроде не было ;D
У тебя получился какой-то промежуточный вариант себестоимости - и не по чисто по партиям и не по партиям-складам, попробуй на экзамене, скажешь что будет ;D
-
Как-то странно с этой задачей по БУ.
Решение с 3 ПУС выводит регистр в ноль, но на экзамене такое решение не принимают...
Получается все же не стоит с этими ПУС заморачиваться и пусть регистр остается несвернутым?
Очень не хочется попасть впросак с этой задачей.
Есть те, кто сделал эту задачу в последние месяцы на экзамене и ее приняли как правильную?
-
Тут вот чел отписался по поводу БУ:
9-го числа мне эта задача попалась на экзамене (там это был билет №14), причем сразу по оперативному и по бухгалтерскому учету.
Решил её так, как в архиве решенных задач (забыл уже где его скачал, к сожалению), использовал 2 ресурса: Количество и Сумма. В реализации сделал 2 соединения с Остатками - одно по Складу/Номенклатуре, другое по Номенклатуре для получения Себестоимости по ФИФО/ЛИФО в рамках всей компании, в измерение склад прописывал склад из реализации. Такое решение приводит к существенной ошибки (снимается 2 бала):
Цитировать
Ресурсы регистра остатков (один или все) изменяются документами и в "+", и в "-", но движения с противоположным знаком для одного того же объекта учета выполняются с разными наборами значений измерений, что также не обеспечивает выведения остатков ресурсов «в ноль».
Соответственно я ошибся в первых двух задачах и получил минус 4, т.е. автоматически не сдал экзамен(
Таким способом решить не получится. Преподаватель понял, что решаю я задачу не правильно ещё только посмотрев движения Прихода, из чего я сделал вывод, что двумя ресурсами не отделаешься и, возможно, надо делать 2 таблицы.
-
И еще вопрос: Кто как реализовал следующее условие по CПР: Сумма оплат должна быть получена по данным бух учета пользователем следующей проводкой:
ДТ «Касса» - Кт «Покупатели» на сумму оплат ?
-
Тут вот чел отписался по поводу БУ:
А что тут нового/странного/важного? Задача решена с очевидной грубой ошибкой.
-
А что можешь посоветовать по поводу СПР, что данные оплаты берутся из БУ. На Сч Касса если повесить аналитику по Сотруднику?
-
А что можешь посоветовать по поводу СПР, что данные оплаты берутся из БУ. На Сч Касса если повесить аналитику по Сотруднику?
Не вижу такой формулировки в 6-СПР. Где такое условие?
-
ВОТ:
Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент. Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. Сумма оплат должна быть получена по данным бух учета пользователем следующей проводкой:
ДТ «Касса» - Кт «Покупатели» на сумму оплат
Считать что после расчета сумма оплат корректировке не подлежит.
Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск, размер которого определяется как количество дней отпуска, умноженное на среднюю дневную ставку.
Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во рабочих дней за пред. 3 месяца. Следует учесть, что данные об отпуске не могут вводиться в систему задним числом.
-
Сумма оплат должна быть получена по данным бух учета пользователем следующей проводкой:
ДТ «Касса» - Кт «Покупатели» на сумму оплат
В актуальных этого нет.
Даже если добавить, то в задаче 6-БУ нет кассы.
-
где здесь читал что комуто попадалось данное условие. Вот собственно текст того, кому попался: Попался билет 6. СПР задача изменена. Нужно было делать перерасчет для начисления,которое рассчитывается по бухгалтерским регистрам. Не сделал.И перерасчет нужно было сделать еще один(плохо помню,по какому начислению) В итоге троечка. из ошибок :
"СПР: Неверно организованны графики, для одного автомобиля не должно быть несколько разных графиков; перерасчет не реализован
-
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.
-
Мой вариант решения, с дополнительным условием в СПР - реализация процедуры перерасчета.
Буду рад критике.
:)
-
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.
Прикладываю точное новое условие по СПР. Такое условие попадается при дистанционной сдаче...
http://forum.chistov.pro/index.php?topic=3670.msg48191#msg48191
-
где здесь читал что комуто попадалось данное условие
Так надо видеть точное условие, чтобы понимать, как получать данные по сотрудникам.
Но на мой взгляд, с/к Сотрудники на счете Касса - не оптимальный вариант. Хотя, если оборотное, может быть.
Прикладываю точное новое условие по СПР. Такое условие попадается при дистанционной сдаче...
http://forum.chistov.pro/index.php?topic=3670.msg48191#msg48191
При таком условии я сделал бы субконто "Сотрудники" на счете "Покупатели" (а в реальной задаче предварительно на счете "Покупатели" создал бы субсчет "Пассажиры", и уже на нем данное субконто).
-
Не очень понятно, как реализовать перерасчет при таких условиях. Есть ли идеи?
-
Не очень понятно, как реализовать перерасчет при таких условиях. Есть ли идеи?
Мой вариант решения 6 СПР с новым условием. Реализацию перерасчета свистнул у Гакусея (нашел в соседних темах).
-
Наконец-то осилил 6 билет по СПР. Программный перерасчёт не делал, т.к. ещё не въезжаю что это и зачем.
Итак, 1 - в условии задачи сказано что возможен обмен автомобилями. По сути здесь у нас автомобили это подразделения. А слово обмен говорит нам, что совместительство невозможно. Т.е. не может человек одновременно ездить на 2 автомобилях, поэтому кидаем автомобиль в реквизит РР.
2 - все сотрудники работают по графику, индивидуальному для каждого автомобиля. Значит автомобили - это и есть графики. Добавляем соотв. измерение в РС графики работы
3 - Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег. Размер суммы одинаков для всех сотрудников и не меняется в течение расчетного периода. Это значит что у нас есть произвольное начисление, которое вообще живёт само по себе. Поэтому кидаем это начисление в ДопНачисления, где у нас никакого периода действия нет. Насчёт фикс. суммы - можно добавить константу, туда пихать число и когда юзер будет набивать нашу фиксу, тупо подтягивать значение из константы. Но я не стал заморачиваться.
4 - Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент. Здесь очень хитрое условие. На мой взгляд задача по СПР должна и решаться механизмами СПР, особенно если в условии явно ничего не указано. Ну или как проще. Поэтому я замутил обычный вид расчета "Оплата пассажиров" и беру его как базу. Это очень удобно. Не нужно городить лишний регистр, можно связать сумму оплат пассажиров и автомобиль, на котором наш сотрудник рубил капусту. Одним словом БАЗА.
5 - Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. Тоже всё понятно - делаем РС с периодичностью месяц и при расчёте базы, аккуратненько подтягиваем этот процент.
6 - Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск, размер которого определяется как количество дней отпуска, умноженное на среднюю дневную ставку. Тут честно говоря, можно словить вакуум от слов "размер" и "определяется", поэтому я забил. Делаем вид расчета отпуск и пусть пользователь вручную его вбивает, с какого и по какое число. Причем какой автомобиль будет указан - неважно. Лишь бы под него была заполнена пятидневка.
7 - Дни отпуска рассчитываются по пятидневному графику. Тут у нас отвисает пачка, мы начинаем нервничать, но не стоит. Решение красивое и простое. Помните, что у нас графики по автомобилям делаются? Логично что никакой автомобиль "пятидневка" или доп.измерение нам городить не нужно и вот почему. Легким движением руки, добавляем второй ресурс пятидневка в наш РС графики работы. И заполняем его всегда программно! Т.е. сб и вс у нас выходные по пятидневке. Всегда. Для всех. Даже если у автомобиля какой-то свой непонятный график, по пятидневке у него своё значение
8 - Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца. Тут всё понятно - используем базу, считать её придётся из 2-х регистров расчета. Не забываем, что отпуск у нас рассчитывается по пятидневке, значит именно по ней мы должны подцепить данные об отработанном времени за пред. 3 месяца
9 - Следует учесть, что данные об отпуске не могут вводиться в систему задним числом. Отлично! Механизм сторнирования не нужно делать!
В принципе всё!
-
Думаю, вид расчета "Оплата пассажиров" - это в корне неверное решение. Мы не начисляем сотруднику "Оплату от пассажиров", это не вид расчета. Тем более, в новом условии задачи данные по оплатам пассажиров берутся по данным бух. учета, так что хочешь-не хочешь, а нужно будет их взять из регистра бухгалтерии.
-
Думаю, вид расчета "Оплата пассажиров" - это в корне неверное решение. Мы не начисляем сотруднику "Оплату от пассажиров", это не вид расчета. Тем более, в новом условии задачи данные по оплатам пассажиров берутся по данным бух. учета, так что хочешь-не хочешь, а нужно будет их взять из регистра бухгалтерии.
Позволю себе заметить, что в регистре расчета нет никаких остатков и в ноль он не закрывается. Соответственно под "начислением сотруднику" можно понимать, что угодно. Я выбрал такое решение и оно работает, в оригинальном условии об этом ничего не сказано.
Что касается последней версии с данными из БУ, то это только облегчает жизнь, т.к. условную проводку можно сделать документом операция и она не затрагивает остальные области учёта в данной задаче.
-
Похоже предыдущие сообщения никто не читает ;D
Краткое содержание - если делать задачу в лоб, то нужно 2 ресурса для количества и 3 пуса. Меньше не получится.
Но хоть в этом варианте и все сходится в 0, он имеет свои недостатки, поэтому его забраковали.
Как делать нормально написано еще до забраковки основного варианта в #236 8)
Dertu, напиши проводки по 1-2 товарам, по ним мы поймем о чем этот вариант и сходится в 0 или нет.
Попалась на экзамене эта задача, решил ее создав забалансовый счет "ТоварыНаСкладах", решение не приняли. Написали, что забалансовый счет лишний. Как же всё-таки решается эта задача?
-
Попалась на экзамене эта задача, решил ее создав забалансовый счет "ТоварыНаСкладах", решение не приняли. Написали, что забалансовый счет лишний. Как же всё-таки решается эта задача?
Значит трактовка задачи в их понимании стала другая.
Я исходил из той трактовки, которую принимали до этого. По ней или делать 2 пуса + 1 ресурс или создавать новый счет для хранения количества по складам.
2 пуса + 1 ресурс забраковали логично, потому что каждый ресурс в регистре бухгалтерии означает новый вид учета. А нового вида учета у нас нет.
Я бы при сдаче подробно расписал свою трактовку:
1. Если считать себестоимость отдельно от складов, то у нас будет 2 разных количества в разрезе номенклатура/партия и номенклатура/склад.
2. Чтобы учесть 2 количества по разным разрезам нужно или 2 пуса и 2 ресурса на одном счете или новый счет.
3. Раз на новом счете нужно хранить только количество, контроль двойной записи не нужен, значит его лучше сделать забалансовым.
Раз такой вариант не устраивает, возможно изменилась трактовка на расчет себестоимости по партиям в разрезе складов. Но тогда задача получается совсем простой, без каких-то настроек, только пу количественный. Есть риск, что и этот вариант не пройдет, т.к. излишнее упрощение.
Лучше конечно узнать у преподавателя трактовку перед сдачей. И в любом случае подробно описывать свою трактовку и вариант решения по шагам.
Возможно каждый преподаватель ждет какое-то свое решение и другие просто не рассматривает. Я бы лично подавал аппеляцию в таком случае.
Сочувствую, что вам попалась эта задача в такой момент, что тут даже профессор бухучета видимо не поможет, нужно уточнять трактовку задачи, что они имеют ввиду.
-
... Как же всё-таки решается эта задача?
Не заморачиваться больше, чем предполагает экз: считать, что "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" по складу, с которого осуществляется реализация.
-
Раз такой вариант не устраивает, возможно изменилась трактовка на расчет себестоимости по партиям в разрезе складов. Но тогда задача получается совсем простой, без каких-то настроек, только пу количественный. Есть риск, что и этот вариант не пройдет, т.к. излишнее упрощение.
Почему вы считаете, что раньше трактовка была сложная?
Большинство решают эту задачу именно "упрощенно", и никто из сдававших не писал, что были проблемы при сдаче.
-
Раз такой вариант не устраивает, возможно изменилась трактовка на расчет себестоимости по партиям в разрезе складов. Но тогда задача получается совсем простой, без каких-то настроек, только пу количественный. Есть риск, что и этот вариант не пройдет, т.к. излишнее упрощение.
Лучше конечно узнать у преподавателя трактовку перед сдачей. И в любом случае подробно описывать свою трактовку и вариант решения по шагам.
Возможно каждый преподаватель ждет какое-то свое решение и другие просто не рассматривает. Я бы лично подавал аппеляцию в таком случае.
Сочувствую, что вам попалась эта задача в такой момент, что тут даже профессор бухучета видимо не поможет, нужно уточнять трактовку задачи, что они имеют ввиду.
Формулировка задачи не изменилась нисколько. Списание номенклатуры с указанного в шапке склада, при этом списание себестоимости ФИФО или ЛИФО по партиям. Все слово в слово.
Пока ждал результат спрашивал у своего знакомого опытнейшего бухгалтера, она сказала, что в жизни такие забалансовые счета создаются без проблем. При этом решение полностью работоспособное было. Если не залазить в механизмы, можно спокойно использовать.
По поводу аппелляции, не вижу смысла, как можно что-то доказать одним письмишком по электронной почте человеку, ведь с ними же просто никакой обратной связи нет.
-
Раз такой вариант не устраивает, возможно изменилась трактовка на расчет себестоимости по партиям в разрезе складов. Но тогда задача получается совсем простой, без каких-то настроек, только пу количественный. Есть риск, что и этот вариант не пройдет, т.к. излишнее упрощение.
Почему вы считаете, что раньше трактовка была сложная?
Большинство решают эту задачу именно "упрощенно", и никто из сдававших не писал, что были проблемы при сдаче.
Все последние сдачи были с 2 пусами и 2 ресурсами, т.е. по сложной трактовке, и ни один предователь не говорил: "а что вы тут нагородили, нужен же только 1 ресурс и все" и cтавили за нее 5 баллов. Т.е. в самой трактовке до сих пор сомнений не было, браковать стали только реализацию этой трактовки с 2 ресурсами.
Я лично не видел, чтобы принимали простую трактовку, для меня лично странно как можно принимать одновременно и сложную и очень простую трактовку и ставить за нее 5 баллов.
Риск есть и там и там. Если уверен в себе, то делай сложную, если не уверен, то простую.
-
Формулировка задачи не изменилась нисколько. Списание номенклатуры с указанного в шапке склада, при этом списание себестоимости ФИФО или ЛИФО по партиям. Все слово в слово.
Пока ждал результат спрашивал у своего знакомого опытнейшего бухгалтера, она сказала, что в жизни такие забалансовые счета создаются без проблем. При этом решение полностью работоспособное было. Если не залазить в механизмы, можно спокойно использовать.
По поводу аппелляции, не вижу смысла, как можно что-то доказать одним письмишком по электронной почте человеку, ведь с ними же просто никакой обратной связи нет.
Формулировка не изменилась. Может измениться трактовка. Т.е. с этого момента преподаватель скажет считаем написанное так-то и так-то, по-другому, чем было.
А то, что преподаватель ждет именно свое решение, а не правильное, это есть примеры в интернете, когда на аппеляции 2 исправляли на 5, т.е. там уже вникают в суть решения, а не просто ждут свое правильное.
-
есть примеры в интернете, когда на аппеляции 2 исправляли на 5, т.е. там уже вникают в суть решения, а не просто ждут свое правильное.
Я сегодня спросил в центре, где сдавал, мне сказали, что с 2003 г. у них всего ОДИН раз исправили оценку после подачи апелляции.
-
Все последние сдачи были с 2 пусами и 2 ресурсами, т.е. по сложной трактовке, и ни один предователь не говорил: "а что вы тут нагородили, нужен же только 1 ресурс и все" и cтавили за нее 5 баллов. Т.е. в самой трактовке до сих пор сомнений не было, браковать стали только реализацию этой трактовки с 2 ресурсами.
Я лично не видел, чтобы принимали простую трактовку, для меня лично странно как можно принимать одновременно и сложную и очень простую трактовку и ставить за нее 5 баллов.
Риск есть и там и там. Если уверен в себе, то делай сложную, если не уверен, то простую.
Откуда у вас информация про "все последние сдачи"?
Посмотрел ветку "Результаты сдачи" за 3 последних месяца, нашел лишь один отзыв с комментарием - учетная схема с 2 количествами некорректна:
http://forum.chistov.pro/index.php?topic=993.msg48841#msg48841
Кстати, тогда вы спрашивали, что раньше все сдавали так (с 2 кол-вами)?:
http://forum.chistov.pro/index.php?topic=993.msg48843#msg48843
Но лично я не помню отзыва, что приняли решение с 2 количествами. И в тоже время раньше был еще ранее по крайней мере один отзыв, что 2 количества не прокатывают.
Плюс к сказанному. Я сдавал чуть более года назад, тогда тут очень активно выкладывали решения, и именно все делали упрощенный вариант, отзывов про замечания за это не было. Тема про 2 количества всплыла месяца через 2 после того, как я сдал, поддержки особой не получила (но я тогда был одним из активных ее сторонников). И никто не написал, что не сдал с одним кол-вом.
Так что даже представить не могу, что вы имеете ввиду, говоря, что раньше все сдавали с 2 количествами.
Ссылка есть?
-
есть примеры в интернете, когда на аппеляции 2 исправляли на 5, т.е. там уже вникают в суть решения, а не просто ждут свое правильное.
Я сегодня спросил в центре, где сдавал, мне сказали, что с 2003 г. у них всего ОДИН раз исправили оценку после подачи апелляции.
Печально, значит суть экзамена больше в том, чтобы угадать решение в голове экзаменатора, а не сделать правильное собственное, хотя может просто редко подают на аппеляцию.
-
Откуда у вас информация про "все последние сдачи"?
Что помню из прочитанного на форумах. Факт, что с 2 ресурсами было одно из популярных решений.
Да и просто прочитать задачу - сложная трактовка самая логичная, легкая тоже имеет право на существование при расположенности к ней преподавателя.
Дальше уже каждый сам выбирает как решать.
-
Товарищи , посмотрел некоторые решения. При решении БУ, перед чтением остатка по счету товары никто не устанавливал блокировку по складу(блокируете только счет,номенклатуру). Почему?
-
Товарищи , посмотрел некоторые решения. При решении БУ, перед чтением остатка по счету товары никто не устанавливал блокировку по складу(блокируете только счет,номенклатуру). Почему?
Потому что себестоимость рассчитывается только в разрезе партий, т.е. может списываться с любого склада, следовательно надо блокировать по всем складам.
-
Доброго времени суток всем присутствующим. Скажите, а кто что думает по поводу условия "...Значение процента для надбавки может изменяться не чаще, чем один раз в месяц."? Я не нашел в ветке обсуждения, мне одному кажется, что эта фраза значит, что процент надо получать с возможной разбивкой в течении периода? Или это настолько очевидно, что даже не обсуждается?
-
Доброго времени суток всем присутствующим. Скажите, а кто что думает по поводу условия "...Значение процента для надбавки может изменяться не чаще, чем один раз в месяц."? Я не нашел в ветке обсуждения, мне одному кажется, что эта фраза значит, что процент надо получать с возможной разбивкой в течении периода? Или это настолько очевидно, что даже не обсуждается?
Это значение хранить в РС с периодичностью месяц, соответственно никаких разбивок.
-
Спасибо. Стало быть, паранойя уже у меня - мерещится то, чего нет...
-
Пожалуйста!!!! Посмотрите мое решение! :) ;)
-
Хотелось бы еще узнать мнение участников форума по поводу измерения/реквизита автомобиль РР.
Вот здесь
http://forum.chistov.pro/index.php?topic=993.msg41978#msg41978
И это не мнение, а верный ответ.
Посмею не согласится с вашим верным ответом, видимо все зависит от экзаменатора, но я сдавала дистанционно (сдавала в сентябре 2016 года), и у меня был 6 билет. Я ссылаясь именно на ваш опыт сдачи, сделала Автомобиль реквизитом, и это было признано ошибкой! Вот текст письма: Расчет - обмен между автомобилями не реализован, должно быть измерение с соответствующими настройками.
Хотя я была твердо уверена, что сделала правильно, было очень обидно.
В нашей компании работает человек, который является экзаменатором в Казахстане, он на мои возмущения прямого ответа не может сказать, т.к. все-таки он экзаменатор, но посоветовал обратить внимание на структуру отчета, если там есть автомобиль, то это уже один из поводов сделать его измерением.
-
Посмею не согласится с вашим верным ответом, видимо все зависит от экзаменатора, но я сдавала дистанционно (сдавала в сентябре 2016 года), и у меня был 6 билет. Я ссылаясь именно на ваш опыт сдачи, сделала Автомобиль реквизитом, и это было признано ошибкой! Вот текст письма: Расчет - обмен между автомобилями не реализован, должно быть измерение с соответствующими настройками.
Хотя я была твердо уверена, что сделала правильно, было очень обидно.
В нашей компании работает человек, который является экзаменатором в Казахстане, он на мои возмущения прямого ответа не может сказать, т.к. все-таки он экзаменатор, но посоветовал обратить внимание на структуру отчета, если там есть автомобиль, то это уже один из поводов сделать его измерением.
Давайте посмотрим, что написано в "Профразработке" по структуре РР.
Раньше я не вникал в этот вопрос, сейчас попытался. Прихожу к мнению, что я согласен с Гончаровым.
Читаем по поводу измерений. Объект учета в этой задаче у нас только Сотрудник, Автомобиль таковым не является, т.к. з/п начисляется сотруднику, не зависимо от того, по какому графику и на каких а/м он работал. Для расчета з/п нас не интересуют записи в разрезе а/м. Следовательно, пока нет необходимости добавлять А/м в измерения.
Читаем про реквизиты. Это произвольные дополнительные поля, могут использоваться для формирования отчетов. Так что А/м в реквизитах и в отчете - это нормально.
Теперь по поводу комментария к вашему решению. Я не понял, а собственно, как должен быть реализован обмен? Учет работы на разных а/м есть (что еще надо?), но одновременно (слова Гончарова) сотрудник работать на разных а/м не может, так что каков может быть смысл в получении разреза Сотрудник-Автомобиль, кроме отчета? Всё-таки, на мой взгляд, экзаменатор, проверявший ваше решение, недостаточно компетентен. Если экз не был принят и всё решила данная задача, надо было писать апелляцию.
-
Посмею не согласится с вашим верным ответом, видимо все зависит от экзаменатора, но я сдавала дистанционно (сдавала в сентябре 2016 года), и у меня был 6 билет. Я ссылаясь именно на ваш опыт сдачи, сделала Автомобиль реквизитом, и это было признано ошибкой! Вот текст письма: Расчет - обмен между автомобилями не реализован, должно быть измерение с соответствующими настройками.
Хотя я была твердо уверена, что сделала правильно, было очень обидно.
В нашей компании работает человек, который является экзаменатором в Казахстане, он на мои возмущения прямого ответа не может сказать, т.к. все-таки он экзаменатор, но посоветовал обратить внимание на структуру отчета, если там есть автомобиль, то это уже один из поводов сделать его измерением.
Давайте посмотрим, что написано в "Профразработке" по структуре РР.
Раньше я не вникал в этот вопрос, сейчас попытался. Прихожу к мнению, что я согласен с Гончаровым.
Читаем по поводу измерений. Объект учета в этой задаче у нас только Сотрудник, Автомобиль таковым не является, т.к. з/п начисляется сотруднику, не зависимо от того, по какому графику и на каких а/м он работал. Для расчета з/п нас не интересуют записи в разрезе а/м. Следовательно, пока нет необходимости добавлять А/м в измерения.
Читаем про реквизиты. Это произвольные дополнительные поля, могут использоваться для формирования отчетов. Так что А/м в реквизитах и в отчете - это нормально.
Теперь по поводу комментария к вашему решению. Я не понял, а собственно, как должен быть реализован обмен? Учет работы на разных а/м есть (что еще надо?), но одновременно (слова Гончарова) сотрудник работать на разных а/м не может, так что каков может быть смысл в получении разреза Сотрудник-Автомобиль, кроме отчета? Всё-таки, на мой взгляд, экзаменатор, проверявший ваше решение, недостаточно компетентен. Если экз не был принят и всё решила данная задача, надо было писать апелляцию.
Спасибо за ваш ответ! попробую добиться еще раз вразумительного ответа от нашего экзаменатора, почему там автомобиль должен был быть именно измерением. У меня помимо этого не были реализованы БП, и отчет не работал по СПР
-
Пожалуйста!!!! Посмотрите мое решение! :) ;)
То что бросилось в глаза:
1. В Регистре бухгалтерии - у ресурса "количество" нужно указать "признак учета". За это "наказывают" на экзамене)
2. Блокировку по складу в БУ я бы не делал, т.к. партия товара может быть "размазана" по складам. На первый взгляд вроде бы не критично, но вдруг с другого склада начнут списывать в этот момент. ХЗ короче.
3. Проблема копеек решается проще : = ?(ОстатокКоличество = 0, 0, ОстатокСумма*КСписаниюКоличество/ОстатокКоличество)
4. БлокироватьДляИзменения = истина, без взведения флага "Разрешить разделение итогов" - не имеет смысла.
-
Читала эту тему, чтобы прояснить условие задачи по СПР. Хочу заметить, не для того, чтобы найти готовое решение, а именно чтобы прояснить условие. До конца этого сделать так и не удалось. Я не понимаю, почему нельзя в билете написать прямо: "при расчете средней дневной ставки отпуска используется количество плановых рабочих дней по такому-то графику". От того, что вместо четкой формулировки написано слово "рабочих" без привязки к графику никому легче не становится: ни экзаменуемым, ни, я думаю, экзаменаторам. А ведь это экзамен для программистов! Очевидно, что здесь должно оцениваться умение программировать, а не умение разгадывать двусмысленные термины. Скажу даже более, не любой опытный консультант сможет сказать, что здесь имелось ввиду. И зачем эти игры, типа, экзаменатор выполняет роль заказчика, и если формулировка непонятна, уточните детали у него (при очной сдаче, конечно, про дистанционную я вообще молчу)? Если всем известно, что на экзамене каждая минута на вес золота. То есть фирма 1С уже изначально как бы подразумевает, что сформулированные ею задания могут неоднозначно трактоваться. Мне кажется, что она просто снимает с себя таким образом ответственность за недостаточно качественную проработку текста задач. Я уверена, что если они использовали бы в заданиях более "математически" однозначные формулировки, то часть условий меняли бы уже в процессе написания как изначально противоречивые. Я еще могу это как-то (с большой натяжкой) оправдать на экзаменах для консультантов, ведь им постоянно приходится общаться с заказчиком, который не всегда в состоянии изложить свои мысли, но зачем так мучить программистов при проверке знаний платформы?
Простите, это был просто крик души :'(
Если в задаче было бы явно сказано, что рабочие дни для ставки отпуска считаются по тому же графику, что и сам отпуск, то однозначно все остальные начисления надо было бы относить в дополнительные без периода действия. Если же было бы сказано, что рабочие дни надо считать по тому графику, по которому работал сотрудник за предшествующие месяцы - то здесь уже однозначно нужно было бы делать ежемесячное начисление (фикс.сумму) с периодом действия. Т.е. из формулировки следовал бы алгоритм решения. А сейчас все остается на произвол экзаменатора и на умение сдающего выкрутится из ситуации, либо ведет к лишним затратам времени на выяснения деталей на очном экзамене. А усугубляется ситуация еще и тем, что использование периода действия для начисления, для которого он не нужен, является серьезной ошибкой.
-
Простите, это был просто крик души :'(
Лишнее это всё, умение трактовать хитрые формулировки на экзамене не проверяется.
Кстати, на экз формулировки могут отличаться от тех, что в тутошнем файлике, иногда довольно существенно.
Так что если вам попалась эта задача, не надо вспоминать, как готовились, а надо внимательно читать и составлять план решения именно той задачи, что в вашем билете.
Если есть двусмысленности, несущественно влияющие на ход решения, а варианты не различаются значительно сложностью, спрашивать необязательно - делайте вариантом, которым покажется более логичным; если экзаменатор спросит про другую трактовку, и вы ответите, как при этом меняется решение, это будет вам плюсом.
Спрашивать экзаменатора вообще говоря надо в том случае, когда есть явные противоречия в условии. Но из тутошнего текста до вашего задания они могут не добраться, однако могут появиться в другой задаче, в которой их нет здесь. Иногда это делается умышленно, чтобы дополнительно проверить понимание сдающим смысла задачи и самостоятельность выполнения (в отличие, например, от зазубривания).
А что вы пишете конкретно по поводу неясности условия, я не понял. И почему вы пишете про рабочие дни? У меня в этой задаче такой текст "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца". Посмотрел своё решение - при вводе фикс суммы записываю факт отработанные дни, при расчете отпуска соответственно уже получаю их по базовому периоду, никакого графика там не надо, тем более, что график устанавливается для автомобиля, а автомобилями сотрудники могут обмениваться.
Кстати, на экз у меня была именно эта задача, никаких претензий со стороны экзаменатора по поводу трактовки не было.
-
А что вы пишете конкретно по поводу неясности условия, я не понял. И почему вы пишете про рабочие дни?
В этой теме раньше уже выкладывали новый вариант этой задачи. Там отработанные дни заменены на рабочие.
Посмотрел своё решение - при вводе фикс суммы записываю факт отработанные дни, при расчете отпуска соответственно уже получаю их по базовому периоду, никакого графика там не надо, тем более, что график устанавливается для автомобиля, а автомобилями сотрудники могут обмениваться.
С отработанными днями все было бы, действительно, проще. Вопрос связан именно с новым текстом задачи.
Кстати, меня посетили еще некоторые мысли, которые делают эту задачу еще более неоднозначной. Есть отчет, в котором начисления выведены в разрезе автомобилей. Но каким образом соотносятся автомобили с начислениями? Выплачивая фиксированную сумму за месяц, мы, скорее всего, будем делать это одной строкой, где автомобиль может быть только один. А что если обмен происходил несколько раз в течение месяца - как это отразить? Разбивать сумму на части кажется бредом. Но с другой стороны, нигде не сказано, что сотрудник весь месяц ездит только на одном автомобиле.
Второй момент, опять же, связанный с отчетом, где начисления в разрезе автомобилей. Сотрудникам выплачивается надбавка за прошлый месяц. В этом месяце сотрудник может ездить уже не на том автомобиле, на котором он ездил, когда получал оплату от пассажиров в прошлом месяце. А поскольку в отчете автомобиль показан, напрашивается вывод: автомобиль все-таки является разрезом учета. Т.е. при получении оплаты от покупателя, похоже, надо указывать не только сотрудника, но и автомобиль, за который платят. Тогда автомобиль логично было бы делать измерением, ведь он здесь уже не только для целей получения графика. Но, с другой стороны, в задаче сказано: "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент." Здесь об автомобиле ни слова. Но как тогда привязать автомобиль к начислениям в отчете, если он не подходит ни к какому начислению вообще никаким боком? К фиксированной сумме толком не подходит, т.к. она в целом за месяц, а в одной строке с этой суммой мы можем показать только один автомобиль - например, тот, на котором он ездил в последний день месяца. К полученной надбавке вообще автомобиль никак не привяжешь, если только не считать поступление денег в разрезе автомобилей, а тогда это уже измерение.
Вообще у меня сейчас складывается такое ощущение, что с автомобилями ситуация здесь еще более мутная, чем с рабочими днями для отпуска. Следуя собственной логике, которую могу обосновать, из-за наличия Надбавки я бы все-таки сделала автомобиль измерением, чтобы было понятно, почему в отчете надбавка относится именно к этому автомобилю - потому что именно по нему получили оплату.
А для того, чтобы разбиение фиксированной суммы по автомобилям в отчете как-то обосновать, я бы, по-хорошему, сделала следующее. Завела бы основное начисление ОтработанноеВремя с периодом действия. По нему вводила бы строки в разрезе автомобилей с указанием дат, суммы бы никакие не начисляла. Фиксированную сумму - в доп. начисления одной строкой без указания дат и автомобиля. В отчете фиксированную сумму распределяла бы между автомобилями пропорционально значению фактического периода действия. Вот тогда я могла бы со спокойной совестью обосновать то, что показано в отчете. Но каким-то уж больно навороченным решение получается. Также вызывает сомнение, насколько корректно добавлять такие вспомогательные начисления.
Была также мысль совместить фикс. сумму с разбиением по автомобилям в одном начислении. В документе заполнять строки с датами и автомобилями без указания сумм, а потом программно распределять значение фикс.суммы (из константы или РС) по строкам набора записей пропорционально их фактическому периоду действия. Но тогда не получится соблюсти условие, что фикс. сумма выплачивается "Не зависимо от отработанного времени ежемесячно". Ведь в какие-то периоды сотрудник может вообще не работать на автомобилях (например, в период отпуска), а фикс. сумму ему начислить надо. Отсюда вывод, что она все-таки должна быть в доп. начислениях без периода действия.
P.S. В основных начислениях автомобиль измерением НЕ делаем. Т.к. наличие периода действия предполагает возможность использования механизма вытеснения. Например, отпуск может вытеснять Отработанное время. Вытеснение будет работать только при совпадающих значениях измерений. У отпуска измерения Автомобиль нет. Следовательно, его не должно быть у основных начислений. А вот в доп. начислениях без периода действия измерение Автомобиль вполне может быть. Доп.начисления относятся к одной общей точке во времени - периоду регистрации, в рамках которого для одного сотрудника может быть надбавка за разные автомобили.
-
Второй момент, опять же, связанный с отчетом, где начисления в разрезе автомобилей. Сотрудникам выплачивается надбавка за прошлый месяц. В этом месяце сотрудник может ездить уже не на том автомобиле, на котором он ездил, когда получал оплату от пассажиров в прошлом месяце. А поскольку в отчете автомобиль показан, напрашивается вывод: автомобиль все-таки является разрезом учета. Т.е. при получении оплаты от покупателя, похоже, надо указывать не только сотрудника, но и автомобиль, за который платят. Тогда автомобиль логично было бы делать измерением, ведь он здесь уже не только для целей получения графика.
"Измерения регистров расчета не связаны с получением аналитики в определенных разрезах" - Профразработка, Глава 13, Измерения регистров расчета.
В разрезе измерений РР действуют механизмы вытеснения и зависимости по базовому периоду. Подробнее - в Профразработке.
Но, с другой стороны, в задаче сказано: "Сотруднику предприятия выплачивается надбавка, рассчитываемая как общая сумма оплат пассажиров за прошлый месяц, полученная сотрудником, умноженная на определенный процент." Здесь об автомобиле ни слова.
Ни слова - это не значит, что нельзя указывать автомобиль при вводе оплат, ведь точно также не сказано, что нельзя вводить оплаты с указанием автомобиля, на итоговую сумму это не повлияет, а для отчета нужно. Я указывал.
Была также мысль совместить фикс. сумму с разбиением по автомобилям в одном начислении. В документе заполнять строки с датами и автомобилями без указания сумм, а потом программно распределять значение фикс.суммы (из константы или РС) по строкам набора записей пропорционально их фактическому периоду действия. Но тогда не получится соблюсти условие, что фикс. сумма выплачивается "Не зависимо от отработанного времени ежемесячно". Ведь в какие-то периоды сотрудник может вообще не работать на автомобилях (например, в период отпуска), а фикс. сумму ему начислить надо.
Можно трактовать и так - "не зависимо от отработанного времени, но всё же при его наличии". И да, делить сумму пропорционально отработанному времени.
Примечание. Думаю, докапываться до таких нюансов ни один экзаменатор не додумается. Вы сейчас не просто заморачиваетесь, где этого не требуется, вы слишком сильно заморачиваетесь на мелочах, которые имеют очень отдаленное отношение к предмету проверки на экзамене.
ПС. Вы в сообщении выше писали, что задачи не проработаны, и это верно, да и логично, что экзаменаторы, иногда таки меняя формулировки, не будут разрабатывать для каждого идеальное ТЗ. Для сдачи экзамена надо знать трактовку стандартных формулировок, влияющих на использование инструментария программы, а не плюхаться в мелочах типа, что к чему прибавить, и что из чего вычесть.
ППС. Еще по поводу дней отработанных и рабочих. Думаю, это лишь изменение формулировки, не влияющее на решение. Поскольку никаких вытеснений, кроме отпуска нет, а отпуск - всегда календарный месяц, то дни отработанные будут совпадать с рабочими днями по графику, если только не вводить фикс сумму в месяце отпуска (значит, и не надо ее вводить, ставим юзеру такое обязательное условие).
-
Вы сейчас не просто заморачиваетесь, где этого не требуется, вы слишком сильно заморачиваетесь на мелочах, которые имеют очень отдаленное отношение к предмету проверки на экзамене.
С этим готова согласиться, знаю за собой такой недостаток :). Возможно потому, что пока не очень хорошо понимаю, что все-таки будет проверять конкретный экзаменатор и стараюсь заранее предусмотреть все возможные ситуации. Предложенное мной выше решение, конечно, надо упрощать. Я попробовала его воплотить в реальность - это заняло три часа. Слишком долго.
"Измерения регистров расчета не связаны с получением аналитики в определенных разрезах" - Профразработка, Глава 13, Измерения регистров расчета.
В разрезе измерений РР действуют механизмы вытеснения и зависимости по базовому периоду. Подробнее - в Профразработке.
В доп. начислениях никакого вытеснения нет. И вовсе не обязательно получать базу по всем измерениям, не все измерения бывают базовыми. То есть в данном случае наличие данного измерения ни на чем бы отрицательно не сказалось. Если сказалось бы - я не понимаю, на чем конкретно. В профразработке об этом не написано. Там сказано, что надо подходить к созданию измерений внимательно и приведен пример со статьей, которую нельзя делать измерением. Но я же не предлагаю делать автомобиль измерением в основных начислениях, где это влияло бы на вытеснение. Это действительно было бы ошибкой. Не понимаю, в чем конкретно выразился бы "вред" от такого измерения в доп.начислениях.
Но согласна, что можно оставить автомобиль реквизитом, при условии, что его не надо выводить в отчет Перерасчеты. Сейчас в этом билете есть такой отчет. Уже понятно, что в источнике данных, из которого будем получать сумму продаж, аналитика Автомобиль должна быть. Ну мне так кажется, по крайней мере. Иначе мы не сможем сопоставить этот источник с разными строками документа начисления ЗП, где указана надбавка одному сотруднику с разными автомобилями (пусть в реквизите). Если бы сделали Автомобиль измерением, могли бы его увидеть в отчете Перерасчеты. Если не делаем измерением - тоже не критично в принципе.
И все-таки меня мучает вопрос. Если поле регистра расчета используется при поиске записи регистра в целях перерасчета, т.е. в каком-то смысле идентифицирует ее, не логичнее ли сделать это поле измерением? Ведь если оно является реквизитом, оно не будет входить в составной индекс, даже если его проиндексировать. А по сочетанию Сотрудник-Автомобиль будут частые соединения с регистром, откуда данные по продажам берутся. По данному сочетанию будет выполняться поиск записей РР из модуля набора записей регистра бухгалтерии (если продажи из проводок, как сейчас в условии) при формировании записей перерасчета. В условии теперь сказано, что при изменении суммы продаж это должно отражаться в отчете Перерасчеты.
-
И все-таки меня мучает вопрос. Если поле регистра расчета используется при поиске записи регистра в целях перерасчета, т.е. в каком-то смысле идентифицирует ее, не логичнее ли сделать это поле измерением?
Честно - не имею ни малейшего представления о хитростях устройства платформы.
Отчетов с перерасчетами много, но все делают по одному принципу: если есть совместительство, подразделение - измерение, нет - реквизит. Никто не писал, что на основании каких-то дополнительных данных экзаменатор требовал делать иначе (в том числе, в этой задаче).
В конце концов, этот экзамен - не на эксперта, а на подготовишку, знающего и правильно использующего базовые принципы работы с платформой.
-
Сегодня на консультации по курсам прояснился вопрос по поводу рабочих дней для расчета отпуска. Они должны рассчитываться по графику самого отпуска. Т.е. данные ни по каким другим графикам получать не надо и доп. ресурс не нужен.
По поводу индексирования для ускорения поиска записей регистра в целях перерасчета: при поиске записей используется составной индекс, а он строится только по базовым измерениям (это из Профразработки). Поскольку автомобиль не можем делать базовым, включение его в состав измерений поиск не ускорит.
-
Сегодня на консультации по курсам прояснился вопрос по поводу рабочих дней для расчета отпуска. Они должны рассчитываться по графику самого отпуска. Т.е. данные ни по каким другим графикам получать не надо и доп. ресурс не нужен.
А что это за график самого отпуска - имеется ввиду пятидневка за 3 предыдущих месяца?
-
А что это за график самого отпуска - имеется ввиду пятидневка за 3 предыдущих месяца?
Да, в условии написано: "Дни отпуска рассчитываются по пятидневному графику". Можем просто взять из Данных графика значение за базовый период по самому начислению Отпуск.
-
Сдал спеца 09.06.17. Хочу поделиться своими решениями билетов. Спасибо всем участникам за обсуждение и выкладываемые решения. Это серьезная помощь в подготовке к экзамену.
-
Задача по ОУ.
Условие
" Каждый стеллаж представляет собой некоторый фиксированный набор комплектующих (например, 4 стойки, 5 полок и 20 болтов). Необходимо обеспечить уникальность деталей, т.е. одна и та же деталь не может относиться к разным стеллажам. "
Сколько посмотрел решений везде добавляется регистр сведений - измерение "Комплектующие", ресурсы "Стеллаж" и "Количество".
Регистр используется только в модуле расходной накладной для замены стеллажа на комплектующие.
В остальном регистр ведётся пользователем.
Номенклатура приходуется на склад, пользователь раскидывает её по стеллажам(заполняет регистр сведений), номенклатура списывается, пользователь сам убирает из регистра сведений проданную номенклатуру.
В регистре накопления "Остатки" только - измерения Склад, Номенклатура и ресурс Количество
Почему решили что этого достаточно? Может нужно ещё измерение "Стеллаж" на регистре остатков, или какой-то новый регистр накопления с данным измерением?
-
СПР
подскажите пожалуйста что значит фраза "возможен обмен автомобилями" ? и нужен ли реквизит "график" или автомобиля связанного с графиком достаточно ?
-
СПР
подскажите пожалуйста что значит фраза "возможен обмен автомобилями" ? и нужен ли реквизит "график" или автомобиля связанного с графиком достаточно ?
сдавал в апреле этого года.
Делал регистр сведений где указывал автомобиль и график(т.к. в задаче сказано: "Установленного для каждого автомобиля отдельно", в тч график не указывается а подтягивается из этого регистра, в регистре расчетов заводятся измерения: Сотрудник и автомобиль(сам сделал еще и график, написали лишнее на экзамене)
-
Осилил ветку...
Остались вопросы.
ОУ:
Почему все делают контроль уникальности Стеллаж-Детал через РС?
Почему не завести реквизиты в номенклатуре: ВидНоменклатуры(Деталь/Стеллаж), Стеллаж (ссылка на номенклатуру с параметром отбора только на ВидНоменклатуры = Стеллаж) и Количество, при записи не давать сохранять номенклатуру вида "Стеллаж" с заполненным реквизитом Стеллаж?
Ну или сделать через подчинение элементам справочника как тут было предложено выше.
На РС ведь свет клином не сошелся.
БУ:
Я так понимаю, все решают через 3 субконто (Номенклатура, Склад, Партия), ПУ Количественный, ПУС Суммовой забивая что на детальных записях регистр в 0 не закрывается.
Есть примеры успешной сдачи такого решения?
UPD: по БУ, я так понимаю, народ забивает на формулировку "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" и списывает партии в разрезе складов :)
-
На счет расчетной задачи
Собака зарыта тут
Каждый автомобиль работает по своему графику пятидневке. И у них могут быть разные дни выходных. Из за этого для расчета рабочего периода командировки требуются графики работы автомобилей. Сами автомобили можно задать как реквизит чисто для отчета.
Бух учет
Если метод расчета себестоимости будет партии в разрезе складов задача считается не решенной...
ну и количество не забываем делать НЕ балансовым с признаком учета
-
Как быть в задачах ОУ и БУ ? Если в ОУ у нас списываются детали, что тогда списывать в БУ? Стеллажи целиком? Тогда они будут приходоваться только ручными операциями или в приходной накладной делать отдельно процедуру приходования по БУ ?
-
Как быть в задачах ОУ и БУ ? Если в ОУ у нас списываются детали, что тогда списывать в БУ? Стеллажи целиком? Тогда они будут приходоваться только ручными операциями или в приходной накладной делать отдельно процедуру приходования по БУ ?
Форум больше читать надо. :)
Проведение ОУ и БУ полностью раздельно. Создаете в РН реквизиты ОУ и БУ типа булево. Проводите по ОУ и/или БУ в зависимости от значений данных реквизитов.
-
А если по БУ также приходовать и списывать детали?
-
Есть доказательства того, что на экзамене можно разделять задачи ОУ и БУ?
-
Есть доказательства того, что на экзамене можно разделять задачи ОУ и БУ?
В обработке проведения пиши код на проводение сразу по ОУ и БУ. Не нужно никаких галочек. ПРосто сразу по ОУ И БУ. Я так делал
-
Тогда в этой конкретно задаче что списывать по БУ? детали или стеллажи целиком?
-
Попытки совмещать ОУ и БУ сродни изобретению велосипеда с квадратными колесами.
На экзамене (во всяком случае - очном), "билеты компонуются случайным образом", а следовательно шанс получить комбинацию задач, которая была отработана при подготовке к экзамену, достаточно мал. К тому же, задачи могут корректироваться, и наработки совмещения окажутся бесполезными даже в отработанной паре задач. Потому оптимально задачи решать полностью независимо, и ввести это в полезную привычку, не заморачиваясь на экзамене на том, на чем заморачиваться нет никакой необходимости.
-
Вопрос по БУ. Почитал эту ветку, вроде бы сошлись на мнении, что списывать по партиям внутри одного склада не правильно, с чем я согласен (фразу "Себестоимость товара рассчитывается в разрезе партий поступления этого товара." на мой взгляд никак иначе трактовать не возможно). Не выведение остатков в ноль по всем субконто тоже серьезная ошибка. Решение с дополнительным РН для контроля остатков в рамках экзамена, на мой взгляд, принципиально не верный путь. Решение с двумя количественными ресурсами приводит к положительному результату, но выглядит не красиво, особенно если попробовать набить движение через операцию. К тому же кто-то из сдававших писал, что на дистанционной сдаче был комментарий: "Учетная схема некорректная, 2 измерения для учета количества". Как в итоге правильно?
-
Что-то никто не обсуждает УФ, а здесь сложный УФ. Получается при выборе Номенклатуры необходимо передать текущую строку в форму списка номенклатуры и на ее основании выполнить запрос. При этом заменяется стандартная обработка списка номенклатуры. Мне не помогда даже то, что я видел решение УФ от Хрома, но не могу понять как оно работает и как происходит эта передача. Может где есть видос на эту задачу, не встречали?
-
Что-то никто не обсуждает УФ
Моя инструкция с экзамена
6 – УФ
Создаем справочник ТипыЦен, вводим предопр, РС ЦеныПродажи (днев, незав., изм Номенклатура, ТипЦен, рес Цена).
У справочника Номенклатура добавляем не осн форму выбора, настраиваем список (произв. запрос, не забываем про NULL цены и кол-ва), добавляем параметры формы для передачи в запрос, добавляем элементы формы Цена и Остаток, настраиваем формат цены, у элемента формы Наименование меняем путь к данным на Ссылка. Создаем процедуру формы ПриСозданииНаСервере, в ней передаем параметры в список, например: Список.Параметры.УстановитьЗначениеПараметра("Период", Параметры.Период); и остальные.
В документе создаем реквизиты ТипЦен, Склад, переносим в форму (или создаем, если ее нет).
В модуле формы документа создаем процедуру НоменклатураНачалоВыбора:
&НаКлиенте
Процедура СписокНоменклатурыНоменклатураНачалоВыбора(Элемент, ДанныеВыбора, СтандартнаяОбработка)
СтандартнаяОбработка = ложь;
ПараметрыФормы = Новый Структура("ТипЦен, Склад, Период", Объект.ТипЦен, Объект.Склад, ТекущаяДата());
ОткрытьФорму("Справочник.Номенклатура.Форма.ФормаВыбораТипЦенИЦена", ПараметрыФормы, Элементы.СписокНоменклатуры);
КонецПроцедуры
В модуле формы справочника процедуру <имяТЧ>ВыборЗначения:
&НаКлиенте
Процедура СписокВыборЗначения(Элемент, Значение, СтандартнаяОбработка)
СтандартнаяОбработка = Ложь;
Тек = Элементы.Список.ТекущиеДанные;
СтрЗн = Новый Структура("Номенклатура, Цена", Тек.Ссылка, Тек.Цена);
ОповеститьОВыборе(СтрЗн);
КонецПроцедуры
В форме документа процедура СписокНоменклатурыОбработкаВыбора:
&НаКлиенте
Процедура СписокНоменклатурыОбработкаВыбора(Элемент, ВыбранноеЗначение, СтандартнаяОбработка)
Тек = Элементы.СписокНоменклатуры.ТекущиеДанные;
ЗаполнитьЗначенияСвойств(Тек, ВыбранноеЗначение);
ЭтаФорма.ТекущийЭлемент.ЗакончитьРедактированиеСтроки(Ложь);
КонецПроцедуры
-
Добрый день, сдавал 18 октября дистанционно в г.Киров. Попался "билет 6", но вместо вопроса по УФ был простой бизнес процесс.
Не сдал, в решении задачи по БУ реализовал неверную учетную схему.
Я сделал доп. счет "ТоварыПартии" на котором учитывал Товары и Партии. Просто схема с двумя количествами на одном счете мне показалась не очень хорошей. В результате получил замечание "некорректная учетная схема". Экзамен не сдан.
Остальные замечания - по мелочи.
СПР
"не сделан отчет" - не успел по времени,
"не сделан перерасчет" - не успел по времени,
"при получении данных базы нет отбора по регистратору" - забываю.......
"использование периода действия для вида расчета не нуждающего в нем"
"неверно настроена адресация"
Очень обидно, но ничего записался на пересдачу. Удачи всем готовящимся и сдающим. Более подробно написал в тему по 6 билету.
Как все таки верно решать БУ задачу из 6 билета? Делать на счете "Товары" 3 субконто "Номенклатура, Склад, Партия" склад не суммовое, партия суммовое и делать два кол-ва?
-
Остальные замечания - по мелочи.
СПР
"не сделан отчет" - не успел по времени,
"не сделан перерасчет" - не успел по времени,
"при получении данных базы нет отбора по регистратору" - забываю.......
"использование периода действия для вида расчета не нуждающего в нем"
"неверно настроена адресация"
С такими "мелочами" даже верная учетная схема не помогла бы. :)
Не реализован приведенный в задании отчет 1,0
Использование регистра расчета, обладающего «Периодом действия» для реализации учета по видам расчета, не обладающих «Периодом действия» 1,5
Неверно заполнен регистр адресации 1,0
-
Вот по замечанию "Использование периода действия для вида расчета не нуждающегося в нем" мне не понятно. Я сохранил свою схему с экзамена в ней у меня отмечено Основные начисления: ФиксированныйОклад, Отпуск.
Доп. начисления: Надбавка.
Я так и сделал, где здесь вид расчета не нуждающийся в исп.периода действия.
Что здесь имеется ввиду, что я не правильно настроил?
-
boroda, что было в задаче по бизнес процессам?
-
Как все таки верно решать БУ задачу из 6 билета?
Меня вот тоже беспокоит этот вопрос. Как методологически правильно реализовать списание по партиям и контроль остатков на складе на одном ресурсе Количество?
-
1. По бизнес процессам процесс из 3 действий, одно из которых групповое. Все просто, я делал за последние 15 минут, но видимо в регистре адресации не все проверил, не назначил адресацию в задаче - связь с измерениями регистра.
2. Если еще раз попадется задача БУ из 6 билета, то буду решать по такой схеме
- на счете товары 3 субконто: Номенклатура, Склад, Партия
- в РБ Управленческий 3 ресурса: Колво, КолвоПартия, Сумма.
- Ресурс Сумма - балансовый
-
- в РБ Управленческий 3 ресурса: Колво, КолвоПартия, Сумма.
Доп ресурс не приветствуется.
Думаю, наименее болезненный с точки зрения штрафов вариант - "не понять", что "себестоимость товара рассчитывается в разрезе партий поступления этого товара" подразумевает "без учета склада", и сделать в разрезе складов. Если сочтут упрощением задачи, выглядит на 0,5 балла. Зато и решение проще и быстрее, больше времени останется на другие задачи.
-
Доп ресурс не приветствуется.
Думаю, наименее болезненный с точки зрения штрафов вариант - "не понять", что "себестоимость товара рассчитывается в разрезе партий поступления этого товара" подразумевает "без учета склада", и сделать в разрезе складов. Если сочтут упрощением задачи, выглядит на 0,5 балла. Зато и решение проще и быстрее, больше времени останется на другие задачи.
[/quote]
Ну как вариант. Я правильно представляю для реализации надо сделать все субконто "Суммовыми" на счете "Товары" и в запросе таб.часть соединять с одной выборкой по остаткам на счете товары по трем субконо?
-
Что-то никто не обсуждает УФ
Моя инструкция с экзамена
6 – УФ
Создаем справочник ТипыЦен, вводим предопр, РС ЦеныПродажи (днев, незав., изм Номенклатура, ТипЦен, рес Цена).
У справочника Номенклатура добавляем не осн форму выбора, настраиваем список (произв. запрос, не забываем про NULL цены и кол-ва), добавляем параметры формы для передачи в запрос, добавляем элементы формы Цена и Остаток, настраиваем формат цены, у элемента формы Наименование меняем путь к данным на Ссылка. Создаем процедуру формы ПриСозданииНаСервере, в ней передаем параметры в список, например: Список.Параметры.УстановитьЗначениеПараметра("Период", Параметры.Период); и остальные.
В документе создаем реквизиты ТипЦен, Склад, переносим в форму (или создаем, если ее нет).
В модуле формы документа создаем процедуру НоменклатураНачалоВыбора:
&НаКлиенте
Процедура СписокНоменклатурыНоменклатураНачалоВыбора(Элемент, ДанныеВыбора, СтандартнаяОбработка)
СтандартнаяОбработка = ложь;
ПараметрыФормы = Новый Структура("ТипЦен, Склад, Период", Объект.ТипЦен, Объект.Склад, ТекущаяДата());
ОткрытьФорму("Справочник.Номенклатура.Форма.ФормаВыбораТипЦенИЦена", ПараметрыФормы, Элементы.СписокНоменклатуры);
КонецПроцедуры
В модуле формы справочника процедуру <имяТЧ>ВыборЗначения:
&НаКлиенте
Процедура СписокВыборЗначения(Элемент, Значение, СтандартнаяОбработка)
СтандартнаяОбработка = Ложь;
Тек = Элементы.Список.ТекущиеДанные;
СтрЗн = Новый Структура("Номенклатура, Цена", Тек.Ссылка, Тек.Цена);
ОповеститьОВыборе(СтрЗн);
КонецПроцедуры
В форме документа процедура СписокНоменклатурыОбработкаВыбора:
&НаКлиенте
Процедура СписокНоменклатурыОбработкаВыбора(Элемент, ВыбранноеЗначение, СтандартнаяОбработка)
Тек = Элементы.СписокНоменклатуры.ТекущиеДанные;
ЗаполнитьЗначенияСвойств(Тек, ВыбранноеЗначение);
ЭтаФорма.ТекущийЭлемент.ЗакончитьРедактированиеСтроки(Ложь);
КонецПроцедуры
Помогло, огромное спасибо!!!!!!!!!!!!!!!!!!!!!!!!!
Но правда один метод у меня не взлетел, я немного переделал:
//////////////////////////////////////////////////////////////
ВРАСХОДНОЙ
&НаКлиенте
Процедура СписокНоменклатурыНоменклатураНачалоВыбора(Элемент, ДанныеВыбора, СтандартнаяОбработка)
// Вставить содержимое обработчика.
СтандартнаяОбработка = Ложь;
Сообщить("НачалоВыбораРасходная");
Структура = Новый Структура("ТипЦены",Объект.ТипЦены);
ОткрытьФорму("Справочник.Номенклатура.Форма.ФормаВыбора1",Структура, Элементы.СписокНоменклатуры);
КонецПроцедуры
&НаКлиенте
Процедура СписокНоменклатурыОбработкаВыбора(Элемент, ВыбранноеЗначение, СтандартнаяОбработка)
// Вставить содержимое обработчика.
СтандартнаяОбработка = Ложь;
Тек = Элементы.СписокНоменклатуры.ТекущиеДанные;
ЗаполнитьЗначенияСвойств(Тек,ВыбранноеЗначение);
КонецПроцедуры
ВСпикеНоменклатуры
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Вставить содержимое обработчика.
СтандартнаяОбработка = Ложь;
Список.Параметры.УстановитьЗначениеПараметра("ТипЦены",Параметры.ТипЦены);
КонецПроцедуры
&НаКлиенте
Процедура СписокВыбор(Элемент, ВыбраннаяСтрока, Поле, СтандартнаяОбработка)
// Вставить содержимое обработчика.
СтандартнаяОбработка = Ложь;
Тек = Элементы.Список.ТекущиеДанные;
Структура = Новый Структура;
Структура.Вставить("Цена",Тек.Цена);
Структура.Вставить("Номенклатура",Тек.Ссылка);
ОповеститьОВыборе(Структура);
КонецПроцедуры
///////////////////////////////////////////////////////////////////////////////////////
-
Я правильно представляю для реализации надо сделать все субконто "Суммовыми" на счете "Товары" и в запросе таб.часть соединять с одной выборкой по остаткам на счете товары по трем субконо?
Если я всё правильно понял (уже 2 года эти задачки не решал) - да.
-
Спсаибо, и главное спасибо за интересное решение, что лучше "не понять задачу" так меньше баллов снимут.
-
Зацените списание в БУ... остальное можно не смотреть. Смысл в том, что списываем количество по партиям прихода на данный склад с рассчитанной себестоимостью в разрезе этой же партии прихода номенклатуры на все склады... При этом "хвосты" суммы оставшиеся по партиям прихода на это склад при списании всего количества по партии, уйдут при списании номенклатуры с других складов по этой партии. На то он и отключенный суммовой признак учета субконто для склада. Как то так...
-
Решение Билета №6 по актуальным билетам рубрикатора. Во вложении реализация задачи по ОУ(1.13) по новой методике проведения, БУ(2.16), ПР(3.40). Критика, альтернативы приветствуются.
-
Кто-нибудь решал СПР по актуальному условию задачи?
http://forum.chistov.pro/index.php?topic=3953.msg48193#msg48193 (http://forum.chistov.pro/index.php?topic=3953.msg48193#msg48193)
-
Помогите разобраться с условием в СПР:
Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск, размер которого определяется как количество дней отпуска, умноженное на среднюю дневную ставку. Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца поделенная на количество отработанных рабочих дней в трех предыдущих месяцах.
1. Я правильно понимаю, что период берем как НачалоМесяца(Дата) и КонецМесяца(Дата)?
2. За количество дней отпуска нужно брать календарные дни или дни пятидневки?
3. Количество рабочих дней в трех предыдущих месяцах нужно считать по пятидневке или рабочих дней по графику автомобиля?
-
Гакусей выкладывал алгоритм программного создания записей в таблице перерасчетов. http://forum.chistov.pro/index.php?topic=993.msg47196#msg47196
Но в этом алгоритме используется ТЗ. Как можно это обойти? Если вынимать из набора значение отбора Регистратор и подсовывать его параметром в запрос к РБ, то такой запрос менее эффективен, чем ТЗ. Любые манипуляции с набор в объектной моделе все равно приводят к потребности передать полученные соответствия Период/Сотрудник в запрос, а кроме как через ТЗ, все решения сводится к запросу в цикле, что еще хуже, чем ТЗ. Получается лучше, чем использование ТЗ для программной записи в таблицу перерасчета не придумать?
-
Коллеги, добрый день!
Просьба прокомментировать решение (если не сложно)
ОУ
Ничего особенного. Состав стеллажей храню в РС - обеспечивает уникальность записей Стеллаж - Деталь.
Реквизит номенклатуры Стеллаж - булево
Проведение по новой методике.
БУ
Хранение в разрезах Номенклатура Партия Склад, Списание в разрезе всех Партий
ПУ - Количественный, ПУС - Суммовй
Счет Товары 3 Субконто: Номенклатура, Склад, Партия. Номенклатура и Партия - суммовый
Счет Покупатели - субконто Сотрудники оборотное - для задачи СПР
Обработка проведения достаточно стандартна. Правда пришлось запрос поотлаживать...
СПР
Делал по новому билету, который выкладывали в этой ветке
Графики:
Сделал РС графики Автомобилей, где пользователь может для любого автомобиля задавать свой график. В РС Графики измерение Автомобиль не использовал.
ПВР:
В ПВР Основные начисления: Оклад (для получения нормы времени), Отпуск (Зависит по базе от всех ВР включая себя)
В ПВР Доп начисления: Надбавка, ведущий сам для себя (для Перерасчета)
В модуле набора записи Регистра бухгалтерии реализовано программное добавление записей в перерасчеты
Обработка проведения Начисления в целом стандартна, но пришлось поотлаживать запросы, что дико бесит, поскольку на экзамене на это времени не будет
УФ
Тут все стандартно
Все отчеты соответствуют форме в задании.
Заранее благодарю за комментарии
-
Коллеги, добрый день!
Просьба прокомментировать решение (если не сложно)
ОУ
Ничего особенного. Состав стеллажей храню в РС - обеспечивает уникальность записей Стеллаж - Деталь.
Реквизит номенклатуры Стеллаж - булево
Проведение по новой методике.
БУ
Хранение в разрезах Номенклатура Партия Склад, Списание в разрезе всех Партий
ПУ - Количественный, ПУС - Суммовй
Счет Товары 3 Субконто: Номенклатура, Склад, Партия. Номенклатура и Партия - суммовый
Счет Покупатели - субконто Сотрудники оборотное - для задачи СПР
Обработка проведения достаточно стандартна. Правда пришлось запрос поотлаживать...
СПР
Делал по новому билету, который выкладывали в этой ветке
Графики:
Сделал РС графики Автомобилей, где пользователь может для любого автомобиля задавать свой график. В РС Графики измерение Автомобиль не использовал.
ПВР:
В ПВР Основные начисления: Оклад (для получения нормы времени), Отпуск (Зависит по базе от всех ВР включая себя)
В ПВР Доп начисления: Надбавка, ведущий сам для себя (для Перерасчета)
В модуле набора записи Регистра бухгалтерии реализовано программное добавление записей в перерасчеты
Обработка проведения Начисления в целом стандартна, но пришлось поотлаживать запросы, что дико бесит, поскольку на экзамене на это времени не будет
УФ
Тут все стандартно
Все отчеты соответствуют форме в задании.
Заранее благодарю за комментарии
БУ пробовали проверять так: http://forum.chistov.pro/index.php?topic=3670.msg43867#msg43867
СПР - я так, понимаю, лучшего варианта кроме как через ТЗ перерасчет по БУ не подобрали? Кстати, зачем там проверка на Активность?
-
БУ пробовали проверять так: http://forum.chistov.pro/index.php?topic=3670.msg43867#msg43867
СПР - я так, понимаю, лучшего варианта кроме как через ТЗ перерасчет по БУ не подобрали? Кстати, зачем там проверка на Активность?
"БУ пробовали проверять так: http://forum.chistov.pro/index.php?topic=3670.msg43867#msg43867" - Да, в базе реализован этот пример. с/с считается корректно
"Кстати, зачем там проверка на Активность?" - это я погорячился. Конечно, там проверки на Активность делать не нужно. Вообще там нужно делать проверку, что объем продаж изменился, иначе записи добавляются просто при перепроведении. Но при такой объемной задаче это уже лишнее.
"СПР - я так, понимаю, лучшего варианта кроме как через ТЗ перерасчет по БУ не подобрали?" - остальные варианты проигрывают и по производительности и по скорости реализации. Возможно в реальной задаче я бы хранил изменения в регистре сведений, а в конце месяца регламентом пересчитывал бы начисления. Но это такое...
-
Да, в базе реализован этот пример. с/с считается корректно
Но остатки все равно кривые. Предложение alex1248 "не понять" мне видится самым оптимальным.
Сделал РС графики Автомобилей, где пользователь может для любого автомобиля задавать свой график. В РС Графики измерение Автомобиль не использовал.
В чем суть этого действа?
-
Да, в базе реализован этот пример. с/с считается корректно
Но остатки все равно кривые. Предложение alex1248 "не понять" мне видится самым оптимальным.
Сделал РС графики Автомобилей, где пользователь может для любого автомобиля задавать свой график. В РС Графики измерение Автомобиль не использовал.
В чем суть этого действа?
В том, чтобы решить задачу, с соблюдением ее условий (Для каждого Авто свой график, Отпуск по пятидневке). Мне такой подход логичнее и удобнее.
Какие проблемы в таком подходе?
-
Да, в базе реализован этот пример. с/с считается корректно
Но остатки все равно кривые. Предложение alex1248 "не понять" мне видится самым оптимальным.
Сделал РС графики Автомобилей, где пользователь может для любого автомобиля задавать свой график. В РС Графики измерение Автомобиль не использовал.
В чем суть этого действа?
БУ. ИМХО считаю что задачу следует понимать следующим образом, для списания мы берем только партии прихода на склад списания, а себестоимость рассчитываем в целом по этой партии, так как одна партия может приходовать одну номенклатура на разные склады с разной стоимостью... в этом контексте себестоимость списания в примере http://forum.chistov.pro/index.php?topic=3670.msg43867#msg43867 для трех единиц будет равна 40, тк партию прихода на другой склад мы не учитываем, в тоже время если бы номенклатура на оба склада приходовалось одной партией тогда себестоимость должна быть 60/5*3=36. Мне кажется что если это и упрощение, то к нему сложно придраться :)
PS. Я там выкладывал решение, кто скачал - оно неверное :)
-
Какие проблемы в таком подходе?
Задача прекрасно решается на одном регистре. Два регистра - претензия на не оптимальное решение.
БУ. ИМХО считаю что задачу следует понимать следующим образом, для списания мы берем только партии прихода на склад списания, а себестоимость рассчитываем в целом по этой партии, так как одна партия может приходовать одну номенклатура на разные склады с разной стоимостью... в этом контексте себестоимость списания в примере http://forum.chistov.pro/index.php?topic=3670.msg43867#msg43867 для трех единиц будет равна 40, тк партию прихода на другой склад мы не учитываем, в тоже время если бы номенклатура на оба склада приходовалось одной партией тогда себестоимость должна быть 60/5*3=36. Мне кажется что если это и упрощение, то к нему сложно придраться :)
PS. Я там выкладывал решение, кто скачал - оно неверное :)
Правильного решения у задачи нет. Варианты решения отличаются только количеством списываемых баллов. В этом плане не выведение в ноль выглядит самым опасным, даже несмотря на то, что проверяющие могут принимать такие решения.
-
Правильного решения у задачи нет. Варианты решения отличаются только количеством списываемых баллов. В этом плане не выведение в ноль выглядит самым опасным, даже несмотря на то, что проверяющие могут принимать такие решения.
а где что в ноль не выводиться в моем решении - ? суммовой признак же отключаем по складу
-
Какие проблемы в таком подходе?
Задача прекрасно решается на одном регистре. Два регистра - претензия на не оптимальное решение.
Можете поделиться своим решением на одном регистре? Мне интересно как вы фиксируете график Отпуска и по каким реквизитам и как настроена связь с графиком
-
а где что в ноль не выводиться в моем решении - ? суммовой признак же отключаем по складу
Вбейте пример:
Приходная1 Товар1 на Склад1, кол-во 1, сумма 5.
Приходная2 Товар1 на Склад2, кол-во 1, сумма 7.
Расходная1 Товар1 со Склад2, кол-во 1, сумма 5 (партия Приходная1).
Затем посмотрите остатки в консоли запросов. Получите суммовые остатки без количественных и количественные без суммовых.
Можете поделиться своим решением на одном регистре? Мне интересно как вы фиксируете график Отпуска и по каким реквизитам и как настроена связь с графиком
Конечно, может быть увидите какие-то проблемы.
-
Можете поделиться своим решением на одном регистре? Мне интересно как вы фиксируете график Отпуска и по каким реквизитам и как настроена связь с графиком
Добавлю еще свои рассуждения по задаче СПР. Может быть найдете в чем я не прав.
[вложение удалено администратором]
-
Вбейте пример:
Приходная1 Товар1 на Склад1, кол-во 1, сумма 5.
Приходная2 Товар1 на Склад2, кол-во 1, сумма 7.
Расходная1 Товар1 со Склад2, кол-во 1, сумма 5 (партия Приходная1).
Затем посмотрите остатки в консоли запросов. Получите суммовые остатки без количественных и количественные без суммовых.
В моем предложении из вашего примера мы вообще ничего списывать не будем с первой партии... в расходной 2 сумма будет 7
но если бы было так -
Приходная1 Товар1 на Склад1, кол-во 1, сумма 5.
Приходная1 Товар1 на Склад2, кол-во 1, сумма 7.
тогда
Расходная1 Товар1 со Склад1, кол-во 1, сумма 6 =(7+5)/2
Расходная2 Товар1 со Склад2, кол-во 1, сумма 6 =(7+5)/2
-
В моем предложении из вашего примера мы вообще ничего списывать не будем с первой партии... в расходной 2 сумма будет 7
но если бы было так -
Приходная1 Товар1 на Склад1, кол-во 1, сумма 5.
Приходная1 Товар1 на Склад2, кол-во 1, сумма 7.
тогда
Расходная1 Товар1 со Склад1, кол-во 1, сумма 6 =(7+5)/2
Расходная2 Товар1 со Склад2, кол-во 1, сумма 6 =(7+5)/2
Проблема возникает до появления Расходная2. Вбейте три документа, посмотрите остатки и вы поймете, что не имеет значения как вы рассчитываете сумму.
-
Проблема возникает до появления Расходная2. Вбейте три документа, посмотрите остатки и вы поймете, что не имеет значения как вы рассчитываете сумму.
короче потестил в консоле до расходной2 , если брать остаток по сумме в разрезе склада будем получать минусы... зачем признак субконто тогда непонятно, видимо пробелы в понимании этого вопроса...
в общем не буду вас больше мучать , спасибо за беседу... )
-
Можете поделиться своим решением на одном регистре? Мне интересно как вы фиксируете график Отпуска и по каким реквизитам и как настроена связь с графиком
Добавлю еще свои рассуждения по задаче СПР. Может быть найдете в чем я не прав.
Крутой разбор задачи. Спасибо.
Я бы не рекомендовал пользоваться разметкой областей на экзамене. Бывает, что из-за них конфигуратор вылетает с ошибкой редактора модулей.
По решению вопросов нет.
-
Я бы не рекомендовал пользоваться разметкой областей на экзамене.
Что за разметка областей?
-
Я бы не рекомендовал пользоваться разметкой областей на экзамене.
Что за разметка областей?
#Область <ИмяОбласти>
#КонецОбласти
Текст ошибки "При редактировании текста модуля произошла внутренняя ошибка"
-
#Область <ИмяОбласти>
#КонецОбласти
Текст ошибки "При редактировании текста модуля произошла внутренняя ошибка"
На экзамене в этом нет необходимости. В коде использовал для того, чтобы визуально делить блоки кода и лучшей ориентации в текстах модуля. Особенно бывает полезно при решении задач ОУ и БУ.
-
Прошу оценить, коллеги.
-
Прошу оценить, коллеги.
Не то, чтобы я готов проверять решения, но из того, что заметил:
1. При использовании новой методики вы в транзакции блокируете запись (БлокироватьДляИзменения). Установка управляемой блокировки уже лишняя и может в некоторых случаях привести к взаимной блокировке.
2. Либо я не увидел, либо нет проверки на незаполненную учетную политику (не критично)
3. Не оптимальный запрос в обработке проведения Расходной накладной. Зачем вы 2 раза выбираете данные из документа (по деталям и по стеллажам), когда можно выбрать все позиции и настроить связь с РС только по стеллажам? (тоже не критично)
4.С/с считаете по партиям в разрезе складов, хотя в условии однозначно сказано, что с/с должна списываться только в разрезе партий. Можно словить -1 балл за упрощение
5. "Проблема копеек" при списании с/с
6. Период в форме Операции. Видел, что вы перед записью устанавливаете нужную дату, но колонку с формы я бы удалил или скрыл.
7. СПР. Почему у вас Отпуск вытесняет Оклад? Условием задачи это не предусмотрено, если я ничего не путаю
8. Зачем вы сначала выгружаете колонку ТЧ в массив, затем обходите ТЧ циклом, потом поиск по массиву с условием. Добавьте переменную булево ВР_Оклад и в цикле по ТЧ
добавьте условие: если ТекСтр.ВидРасчета = Оклад Тогда ВР_Оклад = Истина; КонецЕсли; - ну это так, в глаз ударило.
9. БазовыйПериод в РР допначисления. Там базовый период не нужен.
-
Коллеги скажите, а БУ в этом билете, схема с ПУС КоличествоПартия и КоличествоСклад + Суммовой, уже не прокатывает?
т.е. нужно ПУ Количественный, ПУС Суммовой, на товарах Количественный учет, Суммовой по Номенклатуре и Партии (но не по складу!), а при списании просто 2 раза дёргаем Остатки по счету товары, первый раз получаем КоличествоОстатокДт по счету товары по субконто НоменклатураСклад, второй раз дёргаем остатки и сумму по субконто НоменклатураПартия, а дальше простой обход партий с учетом возможного LIFO/FIFO (сортировка)? Т.е. на самом деле схема даже полегче чем с 3 ПУС и 2мя количествами...
-
Коллеги скажите, а БУ в этом билете, схема с ПУС КоличествоПартия и КоличествоСклад + Суммовой, уже не прокатывает?
т.е. нужно ПУ Количественный, ПУС Суммовой, на товарах Количественный учет, Суммовой по Номенклатуре и Партии (но не по складу!), а при списании просто 2 раза дёргаем Остатки по счету товары, первый раз получаем КоличествоОстатокДт по счету товары по субконто НоменклатураСклад, второй раз дёргаем остатки и сумму по субконто НоменклатураПартия, а дальше простой обход партий с учетом возможного LIFO/FIFO (сортировка)? Т.е. на самом деле схема даже полегче чем с 3 ПУС и 2мя количествами...
Да, наверное, так и следует делать. А 2 количества вообще-то по отзывам никогда не приветствовались. А вот эта принимаемая схема принималась всегда (кто не заморачивался - так и сдавал всегда без проблем). То, что субконто внутри счета не закрывается в ноль, если я не ошибаюсь, неизбежно при использовании ПУСов. Возможно, не стоит так трактовать незакрытие в ноль по субконто, у которых отключен данный ПУС.
-
А почему не закроется?
Да у нас LIFO/FIFO но в целом то, в сумме, количество на складе и количество по всем партия будет равнозначно, соответственно при списании в целом всего остатка по всем складам и партиям оно же тоже уйдет в 0 (как и сумма по партиям)?
-
А почему не закроется?
Да у нас LIFO/FIFO но в целом то, в сумме, количество на складе и количество по всем партия будет равнозначно, соответственно при списании в целом всего остатка по всем складам и партиям оно же тоже уйдет в 0 (как и сумма по партиям)?
Сумма - расход будет не по тому складу, по которому пришла эта партия. В юзерских данных этого не видно, т.к. суммы по складу нет вообще. Но обычный запрос выдает хвостики. Вот и думаю, а ведь при использовании ПУСов так будет всегда. Так что, наверное, так делать можно, иначе пропадает смысл в самих ПУСах.
-
Не то, чтобы я готов проверять решения, но из того, что заметил:
1. При использовании новой методики вы в транзакции блокируете запись (БлокироватьДляИзменения). Установка управляемой блокировки уже лишняя и может в некоторых случаях привести к взаимной блокировке.
2. Либо я не увидел, либо нет проверки на незаполненную учетную политику (не критично)
3. Не оптимальный запрос в обработке проведения Расходной накладной. Зачем вы 2 раза выбираете данные из документа (по деталям и по стеллажам), когда можно выбрать все позиции и настроить связь с РС только по стеллажам? (тоже не критично)
4.С/с считаете по партиям в разрезе складов, хотя в условии однозначно сказано, что с/с должна списываться только в разрезе партий. Можно словить -1 балл за упрощение
5. "Проблема копеек" при списании с/с
6. Период в форме Операции. Видел, что вы перед записью устанавливаете нужную дату, но колонку с формы я бы удалил или скрыл.
7. СПР. Почему у вас Отпуск вытесняет Оклад? Условием задачи это не предусмотрено, если я ничего не путаю
8. Зачем вы сначала выгружаете колонку ТЧ в массив, затем обходите ТЧ циклом, потом поиск по массиву с условием. Добавьте переменную булево ВР_Оклад и в цикле по ТЧ
добавьте условие: если ТекСтр.ВидРасчета = Оклад Тогда ВР_Оклад = Истина; КонецЕсли; - ну это так, в глаз ударило.
9. БазовыйПериод в РР допначисления. Там базовый период не нужен.
1. Да 2-ды заблокировал одну и ту же таблицу, убрал первую блокировку.
2.В целях экономии времени не всегда проверяю, а так и без проверки проведение отрабатывает. Но если позволяет время проверять конечно нужно.
3.Согласен, оптимизировал.
4. Вы хотите сказать нужно ввести признак учета субконто "Суммовой" только для партий?
6. Согласен.
7.Обычно вытесняет, но в задаче так же явно об этом не сказано, вытесняет или не вытесняет, а значит на усмотрение разработчика.
8. Это не оптимально? Если появится еще один вид расчета, потеряется гибкость решения.
-
Коллеги, срочный вопрос. рассматриваю решение билета, в нем автор зачем то (не знаю зачем, хочу понять есть в этом глубинный смысл или это косяк), у ПВР доп начисления лупанул зависимость по базе от Основных начислений и доп начислений. Может это быть связано с дальнейшими перерасчетами по бух регистру или это тупо ошибка? т.к. на мой взгляд доп начисления (надбавка) ни коим образом здесь не имеют никакого периода действия.
-
Коллеги, срочный вопрос. рассматриваю решение билета, в нем автор зачем то (не знаю зачем, хочу понять есть в этом глубинный смысл или это косяк), у ПВР доп начисления лупанул зависимость по базе от Основных начислений и доп начислений. Может это быть связано с дальнейшими перерасчетами по бух регистру или это тупо ошибка? т.к. на мой взгляд доп начисления (надбавка) ни коим образом здесь не имеют никакого периода действия.
Не понимаю зачем вообще в этой задаче зависимость по базе для надбавки, первый показатель сумма оплат берется из оборотного регистра, второй процент из документа начисления.
-
Может это быть связано с дальнейшими перерасчетами по бух регистру или это тупо ошибка?
1) в задаче написано: "Механизм перерасчетов в рамках данной задачи использовать не надо.".
2) что за перерасчет по бух. регистру?
-
1) в задаче написано: "Механизм перерасчетов в рамках данной задачи использовать не надо.".
2) что за перерасчет по бух. регистру?
http://forum.chistov.pro/index.php?topic=3953.msg53929#msg53929
-
Предлагаю свой вариант 6 билета, где условие "Себестоимость товара рассчитывается в разрезе партий поступления этого товара" закрывается в ноль, при этом себестоимость не в разрезе склада. Прошу оценить.
Проводки:
Прих. накладная 1
Болт М12 - 50 шт 2600 руб основной склад
Прих. накладная 2
Болт М12 - 49 шт 2000 руб основной склад
Прих. накладная 3
Болт М12 - 49 шт 2000 руб доп. склад
Расх. накладная 1
Болт М12 - 52 шт основной склад
Болт М12 - 2318,92 руб Прих. накладная 1
Расх. накладная 2
Болт М12 - 47 шт основной склад
Болт М12 - 281,08 руб Прих. накладная 1
Болт М12 - 1814,87 руб Прих. накладная 2
Расх. накладная 3
Болт М12 - 49 шт доп. склад
Болт М12 - 185,13 руб Прих. накладная 2
Болт М12 - 2000 руб Прих. накладная 2
И никаких отрицательных остатков!
В Плане счетов добавлено два ПУ (Количественный и Суммовой) и два ПУС (КоличественныйПризнак и СуммовойПризнак).
На счете Товар для ПУ стоит галка Количественный и Суммовой.
Для ПУС:
на Номенклатуре - КоличественныйПризнак и СуммовойПризнак
на Склад - КоличественныйПризнак
на Партия - СуммовойПризнак
При списании сначала списываем количество без себестоимости по выборке остатки, а потом списываем стоимость без количества другим циклом по выборке партий
и все прекрасно закрывается в ноль что бы вы не делали.
И еще я так понимаю никто по счету Прибыли и убытки в субконто не установил номенклатуру,
а вдруг например клиент захочет выручку в разрезе номенклатуры видеть?
Соотвественно есть смысл добавить субконто.
Для стелажей немножко сложнее, потому что сумма продажи на стелаж, а не на комплектующие в расходной накладной.
Поэтому делаю пропорцию по количеству между комплектующими - так определяю какая выручка на каждую комплектующую приходится.
по СПР
в ПВР Основные начисление только отпуск. Использует период действия, от базы не заивисит.
В ПВР Дополнительные начисления Надбавка и фиксоплата (так как сумма оплаты не зависит от отработанного периода)
Использует период действия - ложь, по базе - зависит по периоду регистрации
РР ОсновныеНачисления
Измернеие - Сотрудник, Ресурс - Результат, Реквизит - Автомобиль (связь с графиком)
Период действия - истина, по графику
РР ДополнителтныеНачисления
Измернеие - Сотрудник, Ресурс - Результат, Реквизит - Автомобиль, ОплатаОтПассажиров (получаю из бух проводок)
Перерасчет по сотруднику
В модуле набора записей бухгалтерии обрабатываю перерасчет
средняя ставка зависит от кол-ва рабочих дней, а не факт. Поэтому количество дней вытаскиваю из РС ГрафикиРаботы запросом. Кто то тут писал, что на экзамене препод так и хотел.
Хотя с другой стороны за это могут снять баллы так как нужно через ПериодДействия, но при этом по ДопНачислениям нет периода действия, в общем тут подумать надо.
-
В Плане счетов добавлено два ПУ (Количественный и Суммовой) и два ПУС (КоличественныйПризнак и СуммовойПризнак).
Огород из ПУ и ПУС вряд ли положительно оценят на экзамене. Я склоняюсь к мнению alex1248.
количество дней вытаскиваю из РС ГрафикиРаботы запросом.
Варианты решений с запросом к РС ГрафикиРаботы не следует вообще рассматривать.
-
средняя ставка зависит от кол-ва рабочих дней, а не факт. Поэтому количество дней вытаскиваю из РС ГрафикиРаботы запросом.
Так лучше не делать.
Если вам нужно кол-во рабочих дней плановое (а не фактическое, за указанный период) берите его из ДанныеГрафика, в том случае, если это необходимо для тарифа/оклада.
Если же это нужно для премии, и прочих доп начислений, заведите ресурс КоличествоРабочихДней, и при записи базы, записывайте в него информацию о кол-ве дней рабочих.
Далее при получении ставки вы просто возьмете БазаКоличествоРабочихдней, и там будет та информация что Вам нужна.
-
В Плане счетов добавлено два ПУ (Количественный и Суммовой) и два ПУС (КоличественныйПризнак и СуммовойПризнак).
Огород из ПУ и ПУС вряд ли положительно оценят на экзамене. Я склоняюсь к мнению alex1248.
количество дней вытаскиваю из РС ГрафикиРаботы запросом.
Я думаю вариант с двумя ресурсами, преподавателю не понравится больше, чем несколько ПУ и ПУС, так как ПУ и ПУС можно настроить для каждого счета отдельно, а вот два ресурса будет висеть для всех счетов всегда, что не очень. Плюс условие задачи выполнено и регистр закрывается в ноль
-
средняя ставка зависит от кол-ва рабочих дней, а не факт. Поэтому количество дней вытаскиваю из РС ГрафикиРаботы запросом.
Так лучше не делать.
Если вам нужно кол-во рабочих дней плановое (а не фактическое, за указанный период) берите его из ДанныеГрафика, в том случае, если это необходимо для тарифа/оклада.
Так как отпуск имеет период действия получаю рабочие дни из ЗначениеБазовыйПериод
-
Так как отпуск имеет период действия получаю рабочие дни из ЗначениеБазовыйПериод
Так вы получите рабочие дни по пятидневке (по графику отпуска), а не по графику автомобиля, как это требуется в задаче. Для фикс.суммы нужен период действия и нужен второй ресурс, на котором будут учитываться раб.дни, и с которого нужно получать базу.
-
Я думаю вариант с двумя ресурсами, преподавателю не понравится больше, чем несколько ПУ и ПУС
Этот вариант решения отрицательно встречается принимающими, об этом уже много написано. Так же много написано про вариант, который принимается. Стоят внимания рассуждения alex1248 на эту тему.
-
Так как отпуск имеет период действия получаю рабочие дни из ЗначениеБазовыйПериод
Так вы получите рабочие дни по пятидневке (по графику отпуска), а не по графику автомобиля, как это требуется в задаче. Для фикс.суммы нужен период действия и нужен второй ресурс, на котором будут учитываться раб.дни, и с которого нужно получать базу.
А вы Фикс. сумму в Осн. начисления или в Доп. Начисления отнесли?
-
А вы Фикс. сумму в Осн. начисления или в Доп. Начисления отнесли?
ОН (период действия): Оклад, Отпуск
ДН: Надбавка
-
Добрый день, Друзья!
Решил задачу по БУ, как говориться в лоб, и получил отчеты как надо.
Встрял с решением СПР и полез сюда читать, как тут решали.
Но, прочитав ветку форума, столкнулся с тем, что, оказывается, многие по незнанию и неопытности делают задачу по БУ не правильно. И, скорей всего, я в числе таких. Так что сел проверять.
Пока читал, пробовал примеры разных людей, того как нужно вбить документы, крутил свою базу с консолью по всякому, чтобы выявить, что и где не сходится и могут вылезти минуса, но попытки были тщетны, все закрывалось в 0 (эх, штука-ирония, не рад тому результату, который хочешь получить). Возможно сказывается уже 5-ый час утра:)
Буду благодарен, если сможете посмотреть мою базу. Может вы свежим взглядом увидите, подскажите.
В базе сделан только функционал по БУ. Делал ее так: ПУ "Количественный" и ПУС "Суммовой". Включил ПУ только для товаров, а для субконто (Склад, Номенклатура, Партия) выключил ПУС "Суммовой" для склада, для остальных оставил. Я специально в расходной закомментировал проведение по ОУ, чтобы не мешал.
А за расчеты я так и не успел сесть, разбирался с БУ:)
-
Буду благодарен, если сможете посмотреть мою базу. Может вы свежим взглядом увидите, подскажите.
В базе сделан только функционал по БУ. Делал ее так: ПУ "Количественный" и ПУС "Суммовой". Включил ПУ только для товаров, а для субконто (Склад, Номенклатура, Партия) выключил ПУС "Суммовой" для склада, для остальных оставил. Я специально в расходной закомментировал проведение по ОУ, чтобы не мешал.
А за расчеты я так и не успел сесть, разбирался с БУ:)
Смотрел только код. Решил так же, думаю что это наиболее корректное решение. Есть один нюанс, у меня не сводились в ноль суммовые остатки в ноль по складу из консоли запросов, хотя суммой ПУС отключен для склада... Перерешал билет с другим порядком субконто для счета товара (откуда у меня возникла такая идея не помню, изначально было - номенклатура,партия,склад, поменял на номенклатура, склад, партия), и о чудо "все как надо играет". Если поменять порядок на живую, то ничего не измениться...
Не претендую на истину, только в качестве наблюдения, возможно у этого есть какая-то теоретическая основа...
-
Смотрел только код. Решил так же, думаю что это наиболее корректное решение. Есть один нюанс, у меня не сводились в ноль суммовые остатки в ноль по складу из консоли запросов, хотя суммой ПУС отключен для склада... Перерешал билет с другим порядком субконто для счета товара (откуда у меня возникла такая идея не помню, изначально было - номенклатура,партия,склад, поменял на номенклатура, склад, партия), и о чудо "все как надо играет". Если поменять порядок на живую, то ничего не измениться...
Не претендую на истину, только в качестве наблюдения, возможно у этого есть какая-то теоретическая основа...
Порядок субконто не должен иметь значения, и решение нужно строить соответствующим образом, т.е. в запросах использовать параметр Субконто, а в блокировках указывать субконто не по его номеру, а по типу. Но в этой задаче проблема не в выводе в ноль, а в наличии суммового остатка при нулевом количественном. Но такое решение принимают, и есть мнение, что это нормально (http://forum.chistov.pro/index.php?topic=3670.msg54123#msg54123).
-
Смотрел только код. Решил так же, думаю что это наиболее корректное решение. Есть один нюанс, у меня не сводились в ноль суммовые остатки в ноль по складу из консоли запросов, хотя суммой ПУС отключен для склада... Перерешал билет с другим порядком субконто для счета товара (откуда у меня возникла такая идея не помню, изначально было - номенклатура,партия,склад, поменял на номенклатура, склад, партия), и о чудо "все как надо играет". Если поменять порядок на живую, то ничего не измениться...
Не претендую на истину, только в качестве наблюдения, возможно у этого есть какая-то теоретическая основа...
Порядок субконто не должен иметь значения, и решение нужно строить соответствующим образом, т.е. в запросах использовать параметр Субконто, а в блокировках указывать субконто не по его номеру, а по типу. Но в этой задаче проблема не в выводе в ноль, а в наличии суммового остатка при нулевом количественном. Но такое решение принимают, и есть мнение, что это нормально (http://forum.chistov.pro/index.php?topic=3670.msg54123#msg54123).
Прошу заметить про блокировки я ничего не говорил, и про параметры запросов тоже, и естественно порядок здесь не причем... Но он имеет значение, например мы все читали умные книжки, в которых есть рекомендации, что чем больше субконто принимает значений, тем ближе оно должно быть к счету это влияет на скорость... Возможно он влияет еще на что то...
В целом я не пытаюсь что-то тут доказать, если не верите, можете сами проверить и опровергнуть... Проблема суммого остатка при нулевом количественном... не знаю, у меня нет такой проблемы, количество по складу ушло сколько нужно,себестоимость в разрезе партии, суммовой по складу не ведем, и запросом его не видим... Я смотрел ваше решение и у вас решено по другому, нежели чем у tuktasa и у меня...
-
В целом я не пытаюсь что-то тут доказать, если не верите, можете сами проверить и опровергнуть...
Я поделился мнением, его не обязательно принимать во внимание.
Проблема суммого остатка при нулевом количественном... не знаю, у меня нет такой проблемы, количество по складу ушло сколько нужно,себестоимость в разрезе партии, суммовой по складу не ведем, и запросом его не видим...
Этот "эффект" (не буду называть это проблемой, т.к. такие решения вроде принимают) не воспроизведется в решениях с двумя количествами (плохой вариант) и при списании по партиям внутри складов.
Я смотрел ваше решение и у вас решено по другому, нежели чем у tuktasa и у меня...
Я уже не помню какое из решений здесь выкладывал. Решал сначала с двумя количествами, затем со списанием по партиям внутри склада, но к экзамену остановился на варианте, что здесь называют "в лоб", но с соответствующим "эффектом".
-
Я уже не помню какое из решений здесь выкладывал. Решал сначала с двумя количествами, затем со списанием по партиям внутри склада, но к экзамену остановился на варианте, что здесь называют "в лоб", но с соответствующим "эффектом".
Есть подозрение что под вариантом "в лоб" люди подразумевают не одно и тоже... )
-
В целом я не пытаюсь что-то тут доказать, если не верите, можете сами проверить и опровергнуть...
Я поделился мнением, его не обязательно принимать во внимание.
Проблема суммого остатка при нулевом количественном... не знаю, у меня нет такой проблемы, количество по складу ушло сколько нужно,себестоимость в разрезе партии, суммовой по складу не ведем, и запросом его не видим...
Этот "эффект" (не буду называть это проблемой, т.к. такие решения вроде принимают) не воспроизведется в решениях с двумя количествами (плохой вариант) и при списании по партиям внутри складов.
Я смотрел ваше решение и у вас решено по другому, нежели чем у tuktasa и у меня...
Я уже не помню какое из решений здесь выкладывал. Решал сначала с двумя количествами, затем со списанием по партиям внутри склада, но к экзамену остановился на варианте, что здесь называют "в лоб", но с соответствующим "эффектом".
Спасибо, Ан, что посмотрели.
Судя из беседы понял, что мой ход мысли и Ан тоже имеет место быть и за это, вроде как, не снижают оценку.
Clition, своим комментарием вы меня успокоили, буду делать на экзамене как и сейчас. Спасибо:) Пойду копать СПР
-
Можете поделиться своим решением на одном регистре? Мне интересно как вы фиксируете график Отпуска и по каким реквизитам и как настроена связь с графиком
Добавлю еще свои рассуждения по задаче СПР. Может быть найдете в чем я не прав.
Добрый день!
Разрешите вставить свои 5 копеек:)
Посмотрел ваше решение, очень понравилось. Было бы время, так же бы расписывал.
Хотел спросить.
1.
ПланСчетов:
• Управленческий
o Предопределенные
Касса
• Субконто
o + Сотрудник (ПУС только Суммовой)
Тут разве не нужно сделать это субконто только оборотным?
2.
ПВР:
•ДН
o Использует период действия: Ложь
o Зависимость от базы: Зависит по периоду регистрации
o Базовые планы видов расчета: ДН
o Предопределенные
+ Надбавка
Тут у вас зависимость по периоду, а разве она тут нужна? Да и в тексте у вас я нигде больше не увидел применение этого признака, хотя и проморгать мог.
-
1.
Тут разве не нужно сделать это субконто только оборотным?
Вы правы, конечно нужно. Видимо не поправил в свое время текст. В рамках задач для дистанционного экзамена субконто ВСЕГДА должно быть оборотным, если по нему не требуется контролировать остаток или остаток не нужен в отчете.
2.
Тут у вас зависимость по периоду, а разве она тут нужна? Да и в тексте у вас я нигде больше не увидел применение этого признака, хотя и проморгать мог.
Для Надбавки нет базовых ВР, но перерасчет на РР можно сделать только для ПВР, у которого есть зависимость по базе. В модуле набора записей РБ мы создаем записи в перерасчете по периоду регистрации, поэтому выбрана зависимость по периоду регистрации. Во всяком случае зависимость по периоду действия выглядит более неправильной. Хотя возможно разницы и нет.
На экзамене попалась эта задача, субконто делал Только обороты, но повесил его не на счет Касса, а на счет Покупатели. Замечаний по этому моменту не было, но если бы сдавал еще раз, то субконто повесил бы все-таки на счет Касса. Кроме того, в обработке проведения НачислениеЗарплаты при получении СуммыОплат, обращался к таблице Обороты РБ, на не к таблице ОборотыДтКт. Опять же замечаний не было, но на мой взгляд это ошибка. Возможно спасло то, что это задача СПР, а не БУ. Перерасчет и ВР Надбавка реализовывал в точности как описывал здесь, замечаний не было. Был ряд других замечаний, которые повлияли на оценку, о которых я отписывался тут:
http://forum.chistov.pro/index.php?topic=4068.msg54609#msg54609 (http://forum.chistov.pro/index.php?topic=4068.msg54609#msg54609)
Если с организацией учета автомобилей теперь ожидание принимающих понятны, то расчет отпуска следует пересмотреть.
-
"Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. "
Что это обозначает?
Регистр сведений "Размеры процентов надбавок" с измерением "Сотрудник" с ресурсом "Процент". Периодичность день?
-
"Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. "
Нужно создавать регистр сведений, но с какой периодичностью?
День или месяц?
-
"Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. "
Я делал с периодичностью месяц без измерений, только ресурс.
-
"Значение процента для надбавки может изменяться не чаще, чем один раз в месяц. В информационной базе необходимо хранить историю его изменения. "
Я делал с периодичностью месяц без измерений, только ресурс.
А для расчета надбавки, размер ее с какой даты брать?
Я на конец периода регистрации документа - Потому что не сказано в условии что на начало берется...
или нужно разбивать по периодам?
например:
1 числа ставка была 10
11 уже стала 20
если брать по значению на конец периода регистрации документа, то сумма будет:
Собрано * 0,20
а с разбивкой будет примерно так
Собрано * (0,10*(10 дней / число дней в месяце) + 0,20*((число дней с 11 и до конца месяца)/Число дней в месяце))
Что правильнее?
-
И еще, я сдавал по этой задаче спеца, и условие там измененное
Принятая оплата с пассажиров должна браться за предыдущий месяц, по сотруднику, по данным бух учета по проводке -
Дт "Касса" Кт "Покупатели "
-
http://forum.chistov.pro/index.php?topic=3670.msg54051#msg54051
http://forum.chistov.pro/index.php?topic=4068.msg54609#msg54609
-
Clition, спасибо тебе...
Сдал спеца. По вопросу "Периодические расчеты" было замечание - "нет перерасчета надбавки при исправлении суммы оплат пассажиров"
Интересно, что по этому вопросу скажете
Идея такая:
В РР добавить поле "Результат". Заполнять сумму по оплатам от пассажиров.
После записи документа "Операция" сверять оборот с суммой по оплатам от пассажиров принятых этим сотрудником. Если есть расхождение то перепроводить регистратор движений по РР.
-
Clition, спасибо тебе...
Сдал спеца. По вопросу "Периодические расчеты" было замечание - "нет перерасчета надбавки при исправлении суммы оплат пассажиров"
Интересно, что по этому вопросу скажете
Идея такая:
В РР добавить поле "Результат". Заполнять сумму по оплатам от пассажиров.
После записи документа "Операция" сверять оборот с суммой по оплатам от пассажиров принятых этим сотрудником. Если есть расхождение то перепроводить регистратор движений по РР.
Мои поздравления!
По поводу перерасчета в свое время Гакусей и pozitiFFF писали как это нужно реализовывать. В своем решении, которое я ранее выкладывал, это было реализовано (обработчик ПриЗаписи в модуле набора записей РБ):
http://forum.chistov.pro/index.php?topic=3670.msg54051#msg54051
-
Попался на экзамене билет, в котором ОУ и ПР из 6 билета.
В РС ГрафикиРаботы добавила Измерение Авто и ресурс ЗначениеПятидневка. Это позволяет период действия использовать только для отпуска.
Перерасчет Надбавки реализован в модуле набора записей регистра бухгалтерии.
Выкладываю экзаменационное решение. В НЕМ ЕСТЬ ОШИБКА
Оценка: 4
Экзамен считается сданным при оценке больше или равной 3.
Комментарий:
Базовый период нужно записывать только для отпуска.
В регистре ДополнительныеНачисления и в модуле документа НачислениеЗарплаты необходимо убрать БазовыйПериод
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
По моему себестоимость рассчитывается не по условию. На складе мы проверяем достаточность количества, себестоимость - в разрезе партий (без учета склада).
Вы же при расчете себестоимости учитываете склад.
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
Вы же при расчете себестоимости учитываете склад.
Думаю можно . если Склад в шапке Док Прихода.
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
Вы же при расчете себестоимости учитываете склад.
Думаю можно . если Склад в шапке Док Прихода.
переработал , с учетом текста задания, и замечаний. null не ставил
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
Вы же при расчете себестоимости учитываете склад.
Думаю можно . если Склад в шапке Док Прихода.
переработал , с учетом текста задания, и замечаний. null не ставил
Упорядочивать надо по моменту времени.
И придерутся к этому или нет, возможно для экзамена допустимо. В этой задаче может получиться, что приход идет на на одну пару склад-партия, а списание может произойти совершенно по другой и может зависнуть количество без суммы для какой нибудь этой пары.
А так вроде хорошо все.
-
Упорядочивать надо по моменту времени.
На сколько я помню
Порядок ПАРТИЯ Автоупоряд-Истина , по ссылочным полям сделает верно так же , как и Партия.МоментВремени
-
В файле , лишь часть задачи БУ . Хочу чтобы посмотрели реализацию настроек для списания и сам код списания . Жду комменты .
В этой задаче может получиться, что приход идет на на одну пару склад-партия, а списание может произойти совершенно по другой и может зависнуть количество без суммы для какой нибудь этой пары.
Честно , я не догоняю ...
Пара: Партия , Склад и (различные номенклатуры ) ведь мы Док Тч обязательно сгруппируем до проведения в рег БУ .
и получается, партияСсылка уникальная , данные из регистра дискретно , построчно ....
ном1. скл1 п1 5шт 10 р
ном2 скл1 п1 3шт 9 р (снова нет ном1)
ном1. скл2 п2 10шт 10 р
ном2 скл2 п2 9шт 9 р (снова нет ном1)
ном1. скл1 п3 8шт 8 р
ном2 скл1 п3 8шт 8 р (снова нет ном1)
если партионные учет, тогда строгая последовательность Возр или убыв по хронологии.
РНК склад шапка . Мы указанием Склада шапки лишь выбираем не все партии.
себестоимость = КоличествоОстаток, СуммаОстаток в 1 партии, т.е.
Для списания Из скл1, ном1 :
Фифо
ном1. скл 1 п1 5шт 10 р
ном1. скл1 п3 8шт 8 р
ост списать 18 шт
с/с1. = партия1 10 р/5шт
с/с2 = партия3 8р/8шт
вот тут я понимаю, что себестоимость у меня в разрезах Партии и Номенклатуры
В запросе же для проверки остатка количества Ном Склад берется сумма кол Ном, склад . Больше чем есть не покажет . И если КоличествоСклад менее
чем нужно мы и так не проведем .
-
Порядок ПАРТИЯ Автоупоряд-Истина , по ссылочным полям сделает верно так же , как и Партия.МоментВремени
Задача АВТОУПОРЯДОЧИВАНИЕ - это вариант сортировки по представлению в ожидаемом для пользователя виде. Вот что написано в ИТС:
На самом деле, упорядочивание по представлению является довольно сомнительной операцией с точки зрения полезности результата. Для примера достаточно посмотреть на представления документов - эти строки содержат в себе даты, а упорядочивание дат как строк не даст осмысленного результата. Для того чтобы обеспечить упорядочивание, которое будет отвечать ожиданиям пользователей, следует использовать упорядочивание непосредственно по ссылочному полю и дополнительно указать в запросе ключевое слово АВТОУПОРЯДОЧИВАНИЕ. В таком случае запрос получит для каждого ссылочного поля реальные поля, по которым его необходимо упорядочить (для документа это будет дата и номер, для справочника - основное представление) и произведет упорядочивание по ним.
Т.е. для документа в сортировке участвует номер и не участвует момент времени. Т.о. это вообще ни одно и тоже.
-
Задача АВТОУПОРЯДОЧИВАНИЕ - это вариант сортировки по представлению в ожидаемом для пользователя виде. Вот что написано в ИТС:
Для того чтобы обеспечить упорядочивание, которое будет отвечать ожиданиям пользователей, следует использовать упорядочивание непосредственно по ссылочному полю и дополнительно указать в запросе ключевое слово АВТОУПОРЯДОЧИВАНИЕ.
Партия-ДокПриходСсылка + Автоупорядочивание .
Скд -поле компоновки Данных -нестандартное упорядочивание по ссылочным тоже +автоупорядочивание .
ДА и не помню , чтоб консоль выдала что то иное от ожидаемого . . .
-
Партия-ДокПриходСсылка + Автоупорядочивание .
Скд -поле компоновки Данных -нестандартное упорядочивание по ссылочным тоже +автоупорядочивание .
ДА и не помню , чтоб консоль выдала что то иное от ожидаемого . . .
На экзамене не достаточно получить правильный результат. На экзамене проверяется знание методологии. Я нигде не видел, чтобы говорилось, что АВТОУПОРЯДОЧИВАНИЕ сортирует по моменту времени. Везде упоминается дата. Не вижу ни одной причины его использовать при наличии для этого специального поля. Я не пытаюсь вас в чем-то убедить. Если считаете ваш вариант правильным - попробуйте его на экзамене.
-
Доброго дня. Выкладываю свое решение. Страшный этот билет, много времени потратил на разбор задачи по СПР.
ОУ, на одном регистре, там вроде все просто, вопросов не возникло.
БУ, ПУ количественный и ПУС Суммовой (установлен для номенклатуры и партии).
СПР, почитав форум решил делать следующим образом.
ОН использует период действия (отпуск имеет протяженность во времени) зависимость от базы по периоду действия (для расчета отпуска нужна база).
ДН зависимость от базы по периоду регистрации. Вообще, по идее здесь база не нужна, но зависимость приходится ставить для перерасчета надбавки.
В регистры добавлены измерение Сотрдуник, реквизит автомобиль .
В РС ГрафикиРаботы добавил измерение автомобиль, ресурс ЗначениеПятидневка (для получения количества рабочих дней по пятидневке).
В оба регистра добавлен перерасчет. В ОН для перерасчета отпуска, в ДН для перерасчета надбавки.
При записи набора РБ хозрасчетный выполняется запись в перерасчет надбавки.
-
Друзья, решаю этот билет и как-то у меня объект "Автомобили" вообще на полет пули не влияет... К отпуску (ОН, период действия) автомобиль отношения никакого не имеет. Дальше. Фиксированная сумма и надбавка (ДопНачисления, без периода действия) от автомобиля тоже никак не зависят. Ну в отчете Автомобиль "ездит". Но где логика? Сотрудник Иванов за месяц может сменить ВСЕ автомобили фирмы. И что? Все виды расчета как считались, так и будут считаться. А в отчеты будет полный бред, если туда запихнуть автомобиль.
В чем я неправа? Подскажите, плиз...
-
Вот и свершилось. БУ попался из билета 3, остальные из билета 6. Все как в актулаьных с учетом изменений. Результат:
Результат экзамена:
Оценка: 3
Экзамен считается сданным при оценке больше или равной 3.
Комментарий:
БП.
Адресация настроена неверно
В РС.РегистрАдресации использовал измерения Исполнитель, Подразделение, Должности. В Задаче во всех реквизитах измерения адресации указал (чтобы не забывать взял за правило при создании первым делом указывать измерение адресации, и название копировать оттуда - быстрее и исключается ошибка). В режиме Предприятия для всех сотрудников отдела продаж (кроме нач. и зам.нач) создал записи с заполненным исполнителем и подразделением. Для начальника и зам.началальников создал записи с заполненным исполнителем, подразделением и должностью. Изначально для начальника и зам.начальников тоже создавал записи с пустыми должностями, но когда начал отладку, то получил дублирование задачи Оповещение о собрании, поэтому удалил.
Clition описывал опыт сдачи в ветке "Обсуждение самого экзамена и результаты сдачи 1С:Специалист 8.3 "
У кого какие идеи по поводу заполнения регистра адресации в этой задаче? Если заполнять так как сначала заполнил Clition - идет дублирование задач. Можно по начальнику и замам делать по 2 записи в регистре(в одной указывать Исполнитель-Должность без Подразделения, в другой Исполнитель-Подразделение без должности). но тогда Должность "Начальник отдела", например, неоднозначна. В данной задаче других отделов нет. Если вводить одну строку по каждому с заполненными Исполнитель-Подразделение-Должность - задачи формируются. Вроде все хорошо. Но Clition снизили за это балл (есть вариант, конечно что не за это :))
Какие будут мысли?
-
Мне мои коллеги (сдавшие спеца) дали вот такую шпаргалку по бизнес-процессам:
-
Считаю, что заполнять нужно по две строки для начальника и замов(одна строка с должностью, другая без) и не обращать внимание на дублирование задач при оповещении.
-
Считаю, что заполнять нужно по две строки для начальника и замов(одна строка с должностью, другая без) и не обращать внимание на дублирование задач при оповещении.
Я так и буду делать, если мне эта задача попадется.
Выкладываю свое решение билета. Буду очень рада критике.
-
Выкладываю свое решение билета. Буду очень рада критике.
Хильда, посмотрел решение только задачи СПР. Есть вопросы.
По условию оплаты нужно получить из бух. учета с условием следующей проводки: Дт «Касса» - Кт «Покупатели». У Вас не указано условие по кредитовому счету. Думаю, лучше указать.
Условие "Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно" у Вас не учтено, как я понял. Работник может работать на разных авто=по разным графикам. Для расчета среднедневной ставки необходимо получать количество рабочих дней с учетом того, что человек мог работать по разным графикам.
-
Slava, аргументирую:
Отпуск считается по Пятидневке - об этом прямо указано в условии. Поэтому для расчета отпуска сотруднику абсолютно фиолетово на каком автомобиле и по какому графику он катался.
Так как в задаче указано, что график устанавливаются для каждого автомобиля, в ввела регистр сведений ГрафикиАвтомобилей. На решение он не влияет, просто самостоятельный объект, рожденный условием задачи.
Кредитовый счет в запросе не использовала, т.к. в нашей задаче Касса больше ни с кем не корреспондирует. Создавать универсальный запрос в рамках экзамена, ИМХО, во-первых, тратить драгоценное время, а во-вторых, не думаю, что будет оценено)))
-
Slava, аргументирую:
Отпуск считается по Пятидневке - об этом прямо указано в условии. Поэтому для расчета отпуска сотруднику абсолютно фиолетово на каком автомобиле и по какому графику он катался.
Так как в задаче указано, что график устанавливаются для каждого автомобиля, в ввела регистр сведений ГрафикиАвтомобилей. На решение он не влияет, просто самостоятельный объект, рожденный условием задачи.
Кредитовый счет в запросе не использовала, т.к. в нашей задаче Касса больше ни с кем не корреспондирует. Создавать универсальный запрос в рамках экзамена, ИМХО, во-первых, тратить драгоценное время, а во-вторых, не думаю, что будет оценено)))
Мутное условие у этой задачи. По поводу отпуска говорится: "Дни отпуска рассчитываются по пятидневному графику" но "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца поделенная на количество рабочих дней в трех предыдущих месяцах". А чтобы получить количество рабочих дней за 3 предыдущих месяца( по пятидневке только отпуск рассчитывается) - нужно учитывать графики автомобилей, на которых работал человек.
Этот "самостоятельный объект, рожденный условием задачи" вызывает подозрения :D
Хотя в этой ветке ранее писали, что на курсах задавали вопрос по поводу этих рабочих дней и было сказано, что рассчитывать их по пятидневке надо.
По поводу учета оплат пассажиров в условии говорится "Сумма оплат должна быть получена по данным бухгалтерского учета с использованием следующей проводки: Дт «Касса» - Кт «Покупатели» на сумму оплат". Я бы не упрощал это условие. Лучше поставить условие на счет «Покупатели»
-
Согласна с ответом на курсах - рабочие дни для отпуска считаются по пятидневке, вне зависимости от того, как работал сотрудник;) Но вообще, это - самое мутное условие задачи из всех билетов.
ПыСы. Плиз, объясните, как вставлять в свой ответ цитаты? Правая верхняя кнопка "Цитировать" тянет у меня ВЕСЬ текст(((
-
Лучше поставить условие на счет «Покупатели»
Именно так. Аргумент экзаменаторов на все аналогичные ситуации - документом "Операция" могут быть введены проводки с произвольной корреспонденцией. В конце концов, иметь привычку всегда делать так - правило хорошего тона в реальной работе.
-
ПыСы. Плиз, объясните, как вставлять в свой ответ цитаты? Правая верхняя кнопка "Цитировать" тянет у меня ВЕСЬ текст(((
После того, как цитата подтянулась целиком - ее можно отредактировать. Потом предварительный просмотр. Если не устраивает результат - продолжать редактировать )
-
alex1248, Slava, спасибо за мнение и помощь! Вы правы - я абсолютно забыла про документ "Операция".
-
alex1248, Slava, спасибо за мнение и помощь! Вы правы - я абсолютно забыла про документ "Операция".
Этим документом и делать проводку по оплате пассажиров. Не надо придумывать новые документы
-
Хильда, мне еще не нравится, что Вы используете автомобиль в ОсновныхРассчетах(касается документа и РР). Там только один ВР "Отпуск", который никак не связан с авто.
-
Slava, мне эта задача вообще не нравится >:( В старом варианте условие хоть логически связанные были, а в новом... :o
И я уже писала выше, что Автомобиль в этой задаче вообще ни к селу, ни к городу... :-\
у меня объект "Автомобили" вообще на полет пули не влияет... К отпуску (ОН, период действия) автомобиль отношения никакого не имеет. Дальше. Фиксированная сумма и надбавка (ДопНачисления, без периода действия) от автомобиля тоже никак не зависят. Ну в отчете Автомобиль "ездит". Но где логика? Сотрудник Иванов за месяц может сменить ВСЕ автомобили фирмы. И что? Все виды расчета как считались, так и будут считаться.
Я его впихнула и в ОН и в ДН, потому что он фигурирует в отчете. Но и в ОН и в ДН он просто "для красоты".
-
мне эта задача вообще не нравится
Мне она тоже не нравилась, и именно она была на экз. Тем не менее никаких придирок от экзаменатора по поводу трактовки условий не было (только имейте ввиду, что задача была без последних изменений).
Вот тут есть пара замечаний, как я делал, и какова была реакция экзаменатора по этой задаче.
http://forum.chistov.pro/index.php?topic=993.msg41978#msg41978
-
Мне она тоже не нравилась, и именно она была на экз. Тем не менее никаких придирок от экзаменатора по поводу трактовки условий не было (только имейте ввиду, что задача была без последних изменений).
Вот тут есть пара замечаний, как я делал, и какова была реакция экзаменатора по этой задаче.
http://forum.chistov.pro/index.php?topic=993.msg41978#msg41978
alex1248, отличие старой формулировки от новой, кроме всего прочего следующее: в старой формулировке "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца" в новой "Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца поделенная на количество рабочих дней в трех предыдущих месяцах". Вы количество отработанных дней получали по графику "пятидневка"?
и в старой и в новой формулировке "Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно" и автомобили можно менять. А "Дни отпуска рассчитываются по пятидневному графику"
-
Вы количество отработанных дней получали по графику "пятидневка"?
Это невозможно. :)
Записывал фактически отработанные дни в регистр при начислении зарплаты, потом получал базу.
Думаю, в новом варианте тоже надо брать дни по фактическому графику.
-
Это невозможно. :)
Записывал фактически отработанные дни в регистр при начислении зарплаты, потом получал базу.
Думаю, в новом варианте тоже надо брать дни по фактическому графику.
Можно добавить второй ресурс "ЗначениеПятидневка" в РС "ГрафикиРабот" и заполнить его по пятидневке. При расчете отпуска брать базу по нему.
А Вы добавляли вид расчета в основные начисления "Отработанные дни" с периодом действия?
-
Можно добавить второй ресурс "ЗначениеПятидневка" в РС "ГрафикиРабот" и заполнить его по пятидневке. При расчете отпуска брать базу по нему.
Для фактически отработанных дней это не имеет смысла. Что делать с фактически отработанными субботами и воскресеньями по 5-дневке?
Что вообще значит "количество отработанных дней по пятидневке"? Отработанные дни - они и в Африке отработанные ;D
А Вы добавляли вид расчета в основные начисления "Отработанные дни" с периодом действия?
Нет, ресурс ОтрабДни в РР Основной, а при проведении дока НЗ - запись в него факт отработанных дней.
-
Нет, ресурс ОтрабДни в РР Основной, а при проведении дока НЗ - запись в него факт отработанных дней.
А по какому виду расчета определяли факт отработанных дней? Мне думается, что в этой задаче только один вид расчета имеет период действия "отпуск", но нам надо получить дни за предыдущие 3 месяца. Не могу понять пока... :-\
-
Slava, а зачем вам фактически отработанные дни? В этой задаче ни на один вид расчета они не влияют.
Фиксированная сумма платиться просто так, всем.
Надбавка зависит от оплат покупателей - сколько заплатят клиенты, столько (в %) получит водитель.
А по отпуску в задаче ПРЯМО сказано - пятидневка. Берем сумму всех начислений сотруднику за три предыдущих месяца (кстати, сюда может и сумма отпускных попасть за прошлый год). Делим на количество РАБОЧИХ дней по пятидневному графику. И умножаем на количество дней отпуска (тоже по пятидневке).
И вся лубоффф. ИМХО ;D
-
Slava, а зачем вам фактически отработанные дни?
Когда деревья были маленькими и alex1248 сдавал экзамен ему попалась эта задача, но тогда в условии фигурировали фактические дни. Вот я и спрашиваю, как он их определял. С пятидневкой я понял. Но хочется "всех посмотреть" :)
-
Нет, ресурс ОтрабДни в РР Основной, а при проведении дока НЗ - запись в него факт отработанных дней.
А по какому виду расчета определяли факт отработанных дней? Мне думается, что в этой задаче только один вид расчета имеет период действия "отпуск", но нам надо получить дни за предыдущие 3 месяца. Не могу понять пока... :-\
А что, задач с зависимостью от кол-ва отработанных дней в базовом периоде больше нет?
Во всяком случае, хотя бы в этой ветке этот вариант обсуждался, читайте с начала ветки и ориентировочно до НГ 2017 (что-то сейчас на форуме вообще спад заметен).
Ну и я выложу еще раз одно из своих решений, вроде бы, в этом моменте оно верно. Но предупреждаю, что за качество решения в целом не отвечаю. ;D
-
А что, задач с зависимостью от кол-ва отработанных дней в базовом периоде больше нет?
Во всяком случае, хотя бы в этой ветке этот вариант обсуждался, читайте с начала ветки и ориентировочно до НГ 2017 (что-то сейчас на форуме вообще спад заметен).
Ну и я выложу еще раз одно из своих решений, вроде бы, в этом моменте оно верно. Но предупреждаю, что за качество решения в целом не отвечаю. ;D
Посмотрел решение. Понял я почему мы друг друга не понимаем :) По последним отчетам о сдаче, сейчас у экзаменаторов считается ошибкой относить оклад в основные начисления. В основных начислениях остается только отпуск.
Спасибо за выложенное решение!
-
alex1248, Slava, спасибо за мнение и помощь! Вы правы - я абсолютно забыла про документ "Операция".
Этим документом и делать проводку по оплате пассажиров. Не надо придумывать новые документы
попался 6 билет, пришел ответ "Нет документа, регистрирующего оплаты от пассажиров (который должен делать запись в таблицу перерасчетов)".
-
попался 6 билет, пришел ответ "Нет документа, регистрирующего оплаты от пассажиров (который должен делать запись в таблицу перерасчетов)".
Igrok, спасибо за информацию!" А можно поподробнее о результатах и подходах к решению))
-
попался 6 билет, пришел ответ "Нет документа, регистрирующего оплаты от пассажиров (который должен делать запись в таблицу перерасчетов)".
Igrok, спасибо за информацию!" А можно поподробнее о результатах и подходах к решению))
Хотел посмотреть ваше решение 6 билета, не нашел)
-
Хотел посмотреть ваше решение 6 билета, не нашел)
Не нравится оно мне. Вот и не выкладывал .
Перерасчет Надбавки реализован в модуле набора записей регистра бухгалтерии.
-
Если в РС "ДанныеГрафика" задать 2 ресурса с графиком авто и пятидневкой, интересно как система рассчитывает фактический период действия для пятидневки, ведь в настройке РР указан ресурс РС с графиком для авто ??? Даже не нашел где об этом почитать :(
-
Если в РС "ДанныеГрафика" задать 2 ресурса с графиком авто и пятидневкой, интересно как система рассчитывает фактический период действия для пятидневки, ведь в настройке РР указан ресурс РС с графиком для авто ??? Даже не нашел где об этом почитать :(
Рассчитает для двух ресурсов. Можно в отладчике посмотреть, как это выглядит
-
Мои решения после сдачи.
-
Хотел посмотреть ваше решение 6 билета, не нашел)
Не нравится оно мне. Вот и не выкладывал .
Перерасчет Надбавки реализован в модуле набора записей регистра бухгалтерии.
Если Выборка.ОбъектПерерасчета = null Тогда
Почему сразу в запросе не отсечь их?
Ну это мелочь.
Я правильно понимаю, вы берете движения со счета Касса-Покупатели, которые водятся задним числом, проверяете были ли по ним начисления, и отсекаете данные по которым уже зафиксированы перерасчеты?
А что вас смущает в вашем решении? Я Протестил решение по бухгалтерии цифры по себестоимости сошлись.
Завтра хочу попробовать на основании вашего прорешать расчеты, на первый взгляд решение адекватное.
-
Почему сразу в запросе не отсечь их?
Ну это мелочь.
Я правильно понимаю, вы берете движения со счета Касса-Покупатели, которые водятся задним числом, проверяете были ли по ним начисления, и отсекаете данные по которым уже зафиксированы перерасчеты?
А что вас смущает в вашем решении? Я Протестил решение по бухгалтерии цифры по себестоимости сошлись.
Завтра хочу попробовать на основании вашего прорешать расчеты, на первый взгляд решение адекватное.
К этому решению пришел за пол часа до того как выложил его. Запись в таблицы перерасчета подсмотрел в решении ИнГор. На следующий день пошел сдавать экзамен.
Не нравится, что рабочие дни за 3 месяца считаются по графику, по которому человек не работал. Условие мутное у задачи. Но решение рабочее.
-
Мои решения после сдачи.
А какой билет попался на экзамене?
-
Мои решения после сдачи.
А какой билет попался на экзамене?
http://forum.chistov.pro/index.php?topic=4068.255
-
Здравствуйте!
Интересует вопрос по получению количества
отработанных дней за предыдущие 3 месяца.
Здесь предлагалось ввести в РР ресурс "ОтработанныеДни"
и туда их записывать, потом брать базу.
Я тоже другого варианта не вижу.
Не выходим ли мы тут на ошибку:
"Решение задач накопления на регистре расчета" -2 балла ?
Т.к. мы фактически накапливаем рабочее время ?
-
Помогите пожалуйста с третьей задачей Расчеты. Не могу понять, почему не работает конструкция программной обработки результатов запроса по Окладу. Запрос к РегистрРасчета.ОН.ДанныеГрафика выдает верный результат, далее идет обычный программный код,
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОНДанныеГрафика.НомерСтроки,
| ЕСТЬNULL(ОНДанныеГрафика.ЗначениеПериодДействия, 0) КАК План,
| ЕСТЬNULL(ОНДанныеГрафика.ЗначениеФактическийПериодДействия, 0) КАК Факт
|ИЗ
| РегистрРасчета.ОН.ДанныеГрафика(
| Регистратор = &Ссылка
| И ВидРасчета = &ВидРасчета) КАК ОНДанныеГрафика";
Запрос.УстановитьПараметр("Ссылка", Ссылка);
Запрос.УстановитьПараметр("ВидРасчета", ПланыВидовРасчета.ОсновныеНачисления.Оклад);
РезультатЗапроса = Запрос.Выполнить();
СтруктураПоиска = Новый Структура("НомерСтроки");
ВДЗ = РезультатЗапроса .Выбрать();
Для Каждого Запись Из Движения.ОН Цикл
Если Запись.ВидРасчета <> ПланыВидовРасчета.ОсновныеНачисления.Оклад Тогда
Продолжить;
КонецЕсли;
СтруктураПоиска.НомерСтроки = Запись.НомерСтроки;
ВДЗ.Сбросить();
Если ВДЗ.НайтиСледующий(СтруктураПоиска) Тогда
Запись.ОтработаноДней = ВДЗ.План;
Запись.Параметр = ВДЗ.Факт;
КонецЕсли;
КонецЦикла;
Движения.ОН.Записать(, Истина);
но почему то, ВДЗ.НайтиСледующий(СтруктураПоиска) дает ЛОЖЬ и выскакивает ошибка
"{ОбщийМодуль.Расчеты.Модуль(45)}: Ошибка при вызове метода контекста (Записать)
Движения.ОН.Записать(, Истина);
по причине:
Недопустимое значение параметра (параметр номер '2') (Необходим пересчет фактического периода действия)
Недопустимое значение параметра (параметр номер '2') (Необходим пересчет фактического периода действия)"
ДТшник во вложении
-
Понял в чем ошибка, у меня почему то в регистрах расчета ОН и ДН не записывается номер строки, вместо номера строки там значение "0". Кто нибудь знает, как подключить в регистре расчета автоматическую нумерацию строк?
-
Понял в чем ошибка, у меня почему то в регистрах расчета ОН и ДН не записывается номер строки, вместо номера строки там значение "0". Кто нибудь знает, как подключить в регистре расчета автоматическую нумерацию строк?
зачем вам и график работы и график автомобиля?
Оклад рассчитывается НЕЗАВИСИМО ОТ ОТРАБОТАННОГО ВРЕМЕНИ. можно привязать к константе.
-
Можно конечно обойтись просто одним регистром ГрафикиРаботы, тем более что на фиксированный оклад, он никак не влияет, а нужен только для расчета базы для отпуска. Тут как бы получилось масло масляное, но я это сделал что бы отработать условие задачи
Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно.
Хотя это можно и не делать по идее. Но у меня вылезла уже не в первой задаче ерунда с тем, что не проставляются номера строк в движениях и я не пойму в чем тут фишка, вчера читал литературу, там сказано что номера строк проставляются автоматически и ничего специально настраивать для этого не нужно, но у меня они не проставляются. Пробовал сделать это программно, но поле Движение.НомерСтроки недоступно для записи
-
Добрый день! И все таки куда правильнее относить фикс. сумму? к Доп начислениям или к Основным?
-
Добрый день!
Кто-нибудь может пояснить:
"Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца."
Про отработанные дни.
Можно ли считать отработанными днями фактическое значение периода действия таблицы ДанныеГрафика с видом расчета Оклад ?
Или есть какая-то другая методика ?
-
Добрый день! И все таки куда правильнее относить фикс. сумму? к Доп начислениям или к Основным?
Все зависит не от основные - дополнительные, а от использует период действия или нет.
Фиксированную сумму раз в месяц платить надо? Если да, период действия не нужен. Если будете за каждый рабочий день платить фисированную сумму, то период действия нужен.
-
Добрый день!
Кто-нибудь может пояснить:
"Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца."
Про отработанные дни.
Можно ли считать отработанными днями фактическое значение периода действия таблицы ДанныеГрафика с видом расчета Оклад ?
Или есть какая-то другая методика ?
Обычно такие задачи решаются добавлением ресурса "ОтработаноДней". При записи пишется не только "Результат" но еще "ОтработаноДней". Потом уже через механизм получения базовых значений получаете БазаОтработаноДней.
-
Добрый день!
Кто-нибудь может пояснить:
"Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца."
Про отработанные дни.
Можно ли считать отработанными днями фактическое значение периода действия таблицы ДанныеГрафика с видом расчета Оклад ?
Или есть какая-то другая методика ?
Обычно такие задачи решаются добавлением ресурса "ОтработаноДней". При записи пишется не только "Результат" но еще "ОтработаноДней". Потом уже через механизм получения базовых значений получаете БазаОтработаноДней.
ComradeKite, спасибо за ответ!
Я выше задавал вопрос, который, впрочем, остался без ответа:
Здравствуйте!
Интересует вопрос по получению количества
отработанных дней за предыдущие 3 месяца.
Здесь предлагалось ввести в РР ресурс "ОтработанныеДни"
и туда их записывать, потом брать базу.
Я тоже другого варианта не вижу.
Не выходим ли мы тут на ошибку:
"Решение задач накопления на регистре расчета" -2 балла ?
Т.к. мы фактически накапливаем рабочее время ?
Что Вы об этом думаете?
Не будет ли правильнее брать ДанныеГрафика за 3 предыдущих месяца, с видом расчета "Оклад",
установив фильтр виртуальной таблицы по этому периоду ?
-
Добрый день!
Кто-нибудь может пояснить:
"Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца."
Про отработанные дни.
Можно ли считать отработанными днями фактическое значение периода действия таблицы ДанныеГрафика с видом расчета Оклад ?
Или есть какая-то другая методика ?
Обычно такие задачи решаются добавлением ресурса "ОтработаноДней". При записи пишется не только "Результат" но еще "ОтработаноДней". Потом уже через механизм получения базовых значений получаете БазаОтработаноДней.
ComradeKite, спасибо за ответ!
Я выше задавал вопрос, который, впрочем, остался без ответа:
Здравствуйте!
Интересует вопрос по получению количества
отработанных дней за предыдущие 3 месяца.
Здесь предлагалось ввести в РР ресурс "ОтработанныеДни"
и туда их записывать, потом брать базу.
Я тоже другого варианта не вижу.
Не выходим ли мы тут на ошибку:
"Решение задач накопления на регистре расчета" -2 балла ?
Т.к. мы фактически накапливаем рабочее время ?
Что Вы об этом думаете?
Не будет ли правильнее брать ДанныеГрафика за 3 предыдущих месяца, с видом расчета "Оклад",
установив фильтр виртуальной таблицы по этому периоду ?
1.задача накопления, это если товар приходовать, то есть реализовать опер учет на регистрах расчета.
2. Данные графика - это план или норма времени. Вам надо факт за три месяца. Но вдруг там болел или еще какие вытеснения.
-
Добрый день!
Кто-нибудь может пояснить:
"Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во отработанных дней за пред. 3 месяца."
Про отработанные дни.
Можно ли считать отработанными днями фактическое значение периода действия таблицы ДанныеГрафика с видом расчета Оклад ?
Или есть какая-то другая методика ?
Обычно такие задачи решаются добавлением ресурса "ОтработаноДней". При записи пишется не только "Результат" но еще "ОтработаноДней". Потом уже через механизм получения базовых значений получаете БазаОтработаноДней.
ComradeKite, спасибо за ответ!
Я выше задавал вопрос, который, впрочем, остался без ответа:
Здравствуйте!
Интересует вопрос по получению количества
отработанных дней за предыдущие 3 месяца.
Здесь предлагалось ввести в РР ресурс "ОтработанныеДни"
и туда их записывать, потом брать базу.
Я тоже другого варианта не вижу.
Не выходим ли мы тут на ошибку:
"Решение задач накопления на регистре расчета" -2 балла ?
Т.к. мы фактически накапливаем рабочее время ?
Что Вы об этом думаете?
Не будет ли правильнее брать ДанныеГрафика за 3 предыдущих месяца, с видом расчета "Оклад",
установив фильтр виртуальной таблицы по этому периоду ?
1.задача накопления, это если товар приходовать, то есть реализовать опер учет на регистрах расчета.
2. Данные графика - это план или норма времени. Вам надо факт за три месяца. Но вдруг там болел или еще какие вытеснения.
ComradeKite, отвечу по пунктам.
1. Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
2. Виртуальная таблица ДанныеГрафика - это не только план (норма времени) - но и факт.
Мы считаем отработанным время, когда человек получал оклад. И в запросе надо делать отбор
по виду расчета "Оклад" и по периоду 3 месяца предыдущих. В итоге получим отработанные часы.
Разве нет ?
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
alex1248, добрый день!
По тем ссылкам, которые у тебя в подписи, я ходил.
И конкретного ответа там нет (если я не заметил - прошу ткнуть).
Я хочу сказать, что задачу можно решать двумя способами:
1. При записи движений по окладу, мы пишем фактически отработанное время.
Для расчета отпуска - читаем его из таблицы База.
2. Мы не пишем эту информацию вместе с окладом.
А для расчета отпуска получаем информацию о фактически отработанных днях из ДанныхГрафика.
Сделав отбор по Окладу и периоду.
И там, и там - фигурирует оклад как ключевое начисление,
определяющее, что человек именно работал.
В 1-м случае мы делаем лишние записи (в дополнительный ресурс РР).
Во 2-м случае - при чтении данных, в запросе, идет лишнее левое соединение.
Что лучше, что хуже - на вкус сдающего.
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
alex1248, добрый день!
По тем ссылкам, которые у тебя в подписи, я ходил.
И конкретного ответа там нет (если я не заметил - прошу ткнуть).
Я хочу сказать, что задачу можно решать двумя способами:
1. При записи движений по окладу, мы пишем фактически отработанное время.
Для расчета отпуска - читаем его из таблицы База.
2. Мы не пишем эту информацию вместе с окладом.
А для расчета отпуска получаем информацию о фактически отработанных днях из ДанныхГрафика.
Сделав отбор по Окладу и периоду.
И там, и там - фигурирует оклад как ключевое начисление,
определяющее, что человек именно работал.
В 1-м случае мы делаем лишние записи (в дополнительный ресурс РР).
Во 2-м случае - при чтении данных, в запросе, идет лишнее левое соединение.
Что лучше, что хуже - на вкус сдающего.
Ну хорошо, попробую предположить чтобы вам сказал экзаменатор за такое решение))
А сказал бы вам он следующее, на мой взгляд конечно:
Экзамен какой сдаете? Правильно, по платформе.
Для выполнения тех или иных действий значит должны использовать типовые платформенные механизмы.
Ну например можно же получить данные грфика из регистра "графики работы" напрямую, можно, но так делать нельзя.
Точно так и с базой. Сказано получение базы, вот и получайте через механизм базы, а не из факта как вы говорите.
Вывод, так решать как предлагаете вы, нельзя.
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
alex1248, добрый день!
По тем ссылкам, которые у тебя в подписи, я ходил.
И конкретного ответа там нет (если я не заметил - прошу ткнуть).
Я хочу сказать, что задачу можно решать двумя способами:
1. При записи движений по окладу, мы пишем фактически отработанное время.
Для расчета отпуска - читаем его из таблицы База.
2. Мы не пишем эту информацию вместе с окладом.
А для расчета отпуска получаем информацию о фактически отработанных днях из ДанныхГрафика.
Сделав отбор по Окладу и периоду.
И там, и там - фигурирует оклад как ключевое начисление,
определяющее, что человек именно работал.
В 1-м случае мы делаем лишние записи (в дополнительный ресурс РР).
Во 2-м случае - при чтении данных, в запросе, идет лишнее левое соединение.
Что лучше, что хуже - на вкус сдающего.
Ну хорошо, попробую предположить чтобы вам сказал экзаменатор за такое решение))
А сказал бы вам он следующее, на мой взгляд конечно:
Экзамен какой сдаете? Правильно, по платформе.
Для выполнения тех или иных действий значит должны использовать типовые платформенные механизмы.
Ну например можно же получить данные грфика из регистра "графики работы" напрямую, можно, но так делать нельзя.
Точно так и с базой. Сказано получение базы, вот и получайте через механизм базы, а не из факта как вы говорите.
Вывод, так решать как предлагаете вы, нельзя.
Сейчас специально читал правила проведения экзамена по платформе.
Не нашел пункта, который бы указывал, что нельзя получать факт часов из таблицы ДанныеГрафика.
Во время подготовки к экзамену, я использовал обе схемы - и так, и так.
Какую буду использовать на экзамене - пока не знаю.
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
alex1248, добрый день!
По тем ссылкам, которые у тебя в подписи, я ходил.
И конкретного ответа там нет (если я не заметил - прошу ткнуть).
Я хочу сказать, что задачу можно решать двумя способами:
1. При записи движений по окладу, мы пишем фактически отработанное время.
Для расчета отпуска - читаем его из таблицы База.
2. Мы не пишем эту информацию вместе с окладом.
А для расчета отпуска получаем информацию о фактически отработанных днях из ДанныхГрафика.
Сделав отбор по Окладу и периоду.
И там, и там - фигурирует оклад как ключевое начисление,
определяющее, что человек именно работал.
В 1-м случае мы делаем лишние записи (в дополнительный ресурс РР).
Во 2-м случае - при чтении данных, в запросе, идет лишнее левое соединение.
Что лучше, что хуже - на вкус сдающего.
Ну хорошо, попробую предположить чтобы вам сказал экзаменатор за такое решение))
А сказал бы вам он следующее, на мой взгляд конечно:
Экзамен какой сдаете? Правильно, по платформе.
Для выполнения тех или иных действий значит должны использовать типовые платформенные механизмы.
Ну например можно же получить данные грфика из регистра "графики работы" напрямую, можно, но так делать нельзя.
Точно так и с базой. Сказано получение базы, вот и получайте через механизм базы, а не из факта как вы говорите.
Вывод, так решать как предлагаете вы, нельзя.
Сейчас специально читал правила проведения экзамена по платформе.
Не нашел пункта, который бы указывал, что нельзя получать факт часов из таблицы ДанныеГрафика.
Во время подготовки к экзамену, я использовал обе схемы - и так, и так.
Какую буду использовать на экзамене - пока не знаю.
Ну это вы так читаете))
Я например читаю вот так
Получение данных графика через таблицу регистра сведений 2,0
-
Опять же, про задачу накопления. Считать рабочее время - это тоже задача накопления. Ну здесь
нас, видимо, никто не рассудит. Т.к. люди отписываются, что учитывали факт часов в регистре расчета
и им не делали замечаний. И в типовых конфигурациях так делают.
Хорошо, эту тему оставим на усмотрение каждого сдающего.
Уверен, что ComradeKite прав.
А вы ходили по ссылке, что у меня в подписи? Мне кажется, что там есть ответ на этот вопрос, и ответ этот от первоисточника.
alex1248, добрый день!
По тем ссылкам, которые у тебя в подписи, я ходил.
И конкретного ответа там нет (если я не заметил - прошу ткнуть).
Я хочу сказать, что задачу можно решать двумя способами:
1. При записи движений по окладу, мы пишем фактически отработанное время.
Для расчета отпуска - читаем его из таблицы База.
2. Мы не пишем эту информацию вместе с окладом.
А для расчета отпуска получаем информацию о фактически отработанных днях из ДанныхГрафика.
Сделав отбор по Окладу и периоду.
И там, и там - фигурирует оклад как ключевое начисление,
определяющее, что человек именно работал.
В 1-м случае мы делаем лишние записи (в дополнительный ресурс РР).
Во 2-м случае - при чтении данных, в запросе, идет лишнее левое соединение.
Что лучше, что хуже - на вкус сдающего.
Ну хорошо, попробую предположить чтобы вам сказал экзаменатор за такое решение))
А сказал бы вам он следующее, на мой взгляд конечно:
Экзамен какой сдаете? Правильно, по платформе.
Для выполнения тех или иных действий значит должны использовать типовые платформенные механизмы.
Ну например можно же получить данные грфика из регистра "графики работы" напрямую, можно, но так делать нельзя.
Точно так и с базой. Сказано получение базы, вот и получайте через механизм базы, а не из факта как вы говорите.
Вывод, так решать как предлагаете вы, нельзя.
Сейчас специально читал правила проведения экзамена по платформе.
Не нашел пункта, который бы указывал, что нельзя получать факт часов из таблицы ДанныеГрафика.
Во время подготовки к экзамену, я использовал обе схемы - и так, и так.
Какую буду использовать на экзамене - пока не знаю.
Ну это вы так читаете))
Я например читаю вот так
Получение данных графика через таблицу регистра сведений 2,0
Полностью согласен с вами,
по этому пункту.
Нельзя получать данные графика через таблицу регистра сведений.
-
Вот если сумму начислений (денег) базы получить не из таблицы базы, а напрямую из регистра,
тогда это 100 % ошибка:
Получение расчетной базы через основную таблицу регистра расчета -2.0.
А с отработанным (фактическим) временем - тут вопрос спорный.
Хотя для расчетов и для получения отчетов - вариант с базовой таблицей
удобнее, без сомнения.
-
А с отработанным (фактическим) временем - тут вопрос спорный.
Добавлю цитатку :)
В задачах получения итоговой информации использование прямого обращения к реальным таблицам регистра без необходимости 1,5
-
А с отработанным (фактическим) временем - тут вопрос спорный.
Добавлю цитатку :)
В задачах получения итоговой информации использование прямого обращения к реальным таблицам регистра без необходимости 1,5
Я и не собирался обращаться к реальным таблицам.
Таблицы База и ДанныеГрафика - это виртуальные таблицы.
-
2. Виртуальная таблица ДанныеГрафика - это не только план (норма времени) - но и факт.
Мы считаем отработанным время, когда человек получал оклад. И в запросе надо делать отбор
по виду расчета "Оклад" и по периоду 3 месяца предыдущих. В итоге получим отработанные часы.
Разве нет ?
А если он был в командировке? Это он "отработал"?
-
2. Виртуальная таблица ДанныеГрафика - это не только план (норма времени) - но и факт.
Мы считаем отработанным время, когда человек получал оклад. И в запросе надо делать отбор
по виду расчета "Оклад" и по периоду 3 месяца предыдущих. В итоге получим отработанные часы.
Разве нет ?
А если он был в командировке? Это он "отработал"?
Lzrnk, мы ставим отбор по виду расчета "Оклад".
Соответственно, если человек был в командировке -
это время не войдет в отработанные часы.
-
2. Виртуальная таблица ДанныеГрафика - это не только план (норма времени) - но и факт.
Мы считаем отработанным время, когда человек получал оклад. И в запросе надо делать отбор
по виду расчета "Оклад" и по периоду 3 месяца предыдущих. В итоге получим отработанные часы.
Разве нет ?
А если он был в командировке? Это он "отработал"?
Lzrnk, мы ставим отбор по виду расчета "Оклад".
Соответственно, если человек был в командировке -
это время не войдет в отработанные часы.
Вот именно. Человек работал, но по вашим расчётам получится, что нет.
Отработал - это не обязательно Оклад. Могут быть командировки, какие-то дежурства, выходы в выходные и т.д.
-
2. Виртуальная таблица ДанныеГрафика - это не только план (норма времени) - но и факт.
Мы считаем отработанным время, когда человек получал оклад. И в запросе надо делать отбор
по виду расчета "Оклад" и по периоду 3 месяца предыдущих. В итоге получим отработанные часы.
Разве нет ?
А если он был в командировке? Это он "отработал"?
Lzrnk, мы ставим отбор по виду расчета "Оклад".
Соответственно, если человек был в командировке -
это время не войдет в отработанные часы.
Вот именно. Человек работал, но по вашим расчётам получится, что нет.
Отработал - это не обязательно Оклад. Могут быть командировки, какие-то дежурства, выходы в выходные и т.д.
Если вы хотите принять, что человек в командировке, дежурства, выходы в выходные и т.д. - это отработанное время,
то 2 варианта:
- при расчете каждого из этих видов расчета, записывать факт часов в ресурс РР "ЧасыФакт".
И брать в базе сумму этих часов (наряду с деньгами).
- или при запросе Данных Графика устанавливать отбор по этим видам расчета (т.е. ВидРасчета в (&ВидыРасчета)).
-
Мое решение 6-го билета. Критике буду рад.
ОУ: В решениях в этой ветке видел структуру: РегистрСведений.СоставСтеллажей
Измерения: Деталь Ресурсы: Стеллаж, Количество.
Вроде все по условию задачи, но нашел я такой пост:
https://forum.chistov.pro/index.php?topic=1026.135
Измерение: Деталь
Ресурсы: Стеллаж, Количество.
При продаже стеллажа, необходимо списывать комплектующие. Вот запросом я соединяюсь к регистру сведений к ресурсу Стеллаж, при условии что номенклатура из ТЧ - это стеллаж и получаю состав стеллажа, далее как обычно, списываю.
Результат экзамена:
ОУ: неверно организовано хранение информации о составе стеллажа, регистры предназначены для быстрого получения информации по измерениям, а не ресурсам;
Пост от 2012 г.
Вот и вопрос: есть ли информация от сдававших, как сейчас? Считается ошибкой, когда Стеллаж в ресурсах?
Я сделал: Измерения: Стеллаж, Деталь; Ресурсы: Количество; Контроль уникальности деталей - в модуле набора записей ПередЗаписью.
Но все же сомневаюсь...
11.06.2018: поправил отчет НаличиеДеталей
12.06.2018: поправил в расходной обработку проведения БУ: разделил запрос на получение сначала количественных остатков, потом - суммовых, чтобы сделать отбор в параметрах виртуальной таблицы по Субконто2 (Партия).
-
alex1248, Slava, спасибо за мнение и помощь! Вы правы - я абсолютно забыла про документ "Операция".
Этим документом и делать проводку по оплате пассажиров. Не надо придумывать новые документы
попался 6 билет, пришел ответ "Нет документа, регистрирующего оплаты от пассажиров (который должен делать запись в таблицу перерасчетов)".
А есть у кого инфа, точно ли требуется этот документ. Сделать не проблема, но в задании о добавлении документа ни слова, а добавление "левых" объектов конфигурации насколько я знаю карается )
-
...
Я сделал: Измерения: Стеллаж, Деталь; Ресурсы: Количество; Контроль уникальности деталей - в модуле набора записей ПередЗаписью.
Но все же сомневаюсь...
Думаю правильная реализация данного момента следующая:
Регистр "СоставКомплектов":
Измерения:
Стеллаж (Тип: справочник Стеллажи)
Деталь (Тип: справочник детали или номенклатура, который подчинен справочнику Стеллажи)
Рекурсы:
Количество (Тип: число)
-
кто нибудь может внести ясность по условию задачи по СПР!!!???
Зачем график для каждого авто, если ежемесячно выплачивается Фикс. Сумма которая никак не зависит от графика, так же надбавка которая зависит только от суммы оплат пассажиров. Оба вида расчета непериодические. Отпуск считается по пятидневке....
И откуда в обсуждениях взялся Оклад, если в задаче о нем ни слова
-
И откуда в обсуждениях взялся Оклад, если в задаче о нем ни слова
Смотрю раздичные решения этого билета и подозреваю, что под окладом подразумевается сумма фиксированного начисления.
Evgenich, как вы думаете, сумма фиксированного начисления должна в базе храниться в виде константы или в регистре сведений? Я больше склоняюсь ко второму варианту, тк в условии сказано, что может менься раз в месяц, но, с другой стороны, если нужен регистр сведений, то в задачах обычно требуют хранить историю изменений.
-
Смотрю раздичные решения этого билета и подозреваю, что под окладом подразумевается сумма фиксированного начисления.
Предполагаю, что так оно и есть, но у меня ни как не укладывается в голове тот факт что ФиксСумма выплачивается независимо от отработанного времени и независимо от того на каком авто он работал, и следовательно для выплаты ФиксСуммы не надо указывать авто и период действия данного вида расчеты, тогда не понятно зачем в условии задачи графики для авто
так же не понятен момент с авто, почему надо при оплате ФиксСуммы указывать одно конкретное авто, зачем тогда условие что возможен обмен,
опять же (из слой сдающих, что авто должно быть измерением по аналогии с подразделением) , тогда за месяц надо для одного сотрудника указывать ФиксСуммы по всем авто на которых он работает, но в абзаце про оплату ФиксСуммы про это опять же не сказано ни слова
и это еще не все размышления по поводу решения СПР из данного билета и все они приводят в тупик, голова уже кругом, что хотят экзаменаторы не понятно...
Evgenich, как вы думаете, сумма фиксированного начисления должна в базе храниться в виде константы или в регистре сведений? Я больше склоняюсь ко второму варианту, тк в условии сказано, что может менься раз в месяц, но, с другой стороны, если нужен регистр сведений, то в задачах обычно требуют хранить историю изменений.
раз в задаче не сказано что нужно хранить историю, то я ФиксСумму сделал константой, и в условии не говорится что может меняться раз в месяц (когда в других задачах это четко указывается) , а указывается лишь то что не меняется в течение расчетного периода, но в моем понимании это не говорит о том, что надо делать регистр сведений с периодичностью в месяц, ведь тогда будет хранится история изменения, а по задаче этого не требуется ))) Наверно главное объяснить экзаменатору, почему вы приняли такое решение )))
-
тогда не понятно зачем в условии задачи графики для авто
Как я вижу. Для рассчета отпускных нужно количество рабочих дней за последние 3 месяца, оно и определяется исходя из графика для авто. То есть у регистра расчета надо создать ресурс для подсчета рабочих дней. При записи в РР информации о Фиксированной сумме записывать еще и количество рабочих дней.
PS. я только начала подготовку и прошу простить, если вдруг глупости каки-нибудь пишу ;)
-
... тогда не понятно зачем в условии задачи графики для авто
я так понимаю это чтобы количество рабочих дней в разрезе графика авто посчитать
-
Смотрю прям больная тема эти расчеты . в каждой ветке о них разговор .
про новую методику проведения вообще забыли . не в одном решении здесь не встретил)) ай молодца
-
У меня ОУ по новой методике, но показывать вам я не собираюсь, не нравитесь вы мне, ходите по веткам, критикуете всех, а сами то ничего до сих пор и не выкладывали и не аргументировали. Кстати так ни дождался от вас решенного третьего билета на оценку "отлично", а так хотелось посмотреть сие творение
-
... тогда не понятно зачем в условии задачи графики для авто
я так понимаю это чтобы количество рабочих дней в разрезе графика авто посчитать
Сам я отчеты эти не читал но в этой ветке есть такой пост
А что, задач с зависимостью от кол-ва отработанных дней в базовом периоде больше нет?
Во всяком случае, хотя бы в этой ветке этот вариант обсуждался, читайте с начала ветки и ориентировочно до НГ 2017 (что-то сейчас на форуме вообще спад заметен).
Ну и я выложу еще раз одно из своих решений, вроде бы, в этом моменте оно верно. Но предупреждаю, что за качество решения в целом не отвечаю. ;D
Посмотрел решение. Понял я почему мы друг друга не понимаем :) По последним отчетам о сдаче, сейчас у экзаменаторов считается ошибкой относить оклад в основные начисления. В основных начислениях остается только отпуск.
Спасибо за выложенное решение!
так же где то здесь писали (не смог найти но
Slava с 421 посте это подтверждает и в следующем посте Хильда подтвердила, что на курсах Отпуск именно так и считается) , что уточняли у экзаменатора по поводу ВР Отпуск, ответ был такой, что Для Отпуска четко указано что он рассчитывается по пятидневке , следовательно и количество рабочих дней брать по пятидневке.
-
Экзаменаторы, пересмотрите условие задачи и удалите текст про автомобили
-
Смотрю прям больная тема эти расчеты . в каждой ветке о них разговор .
про новую методику проведения вообще забыли . не в одном решении здесь не встретил)) ай молодца
Ох уж эти троли, Вы хотите чтоб здесь элементарные вещи вам разжевали?
-
этой элементарной техники не в одном решении тут . сам леприкон
-
Вопрос для Clition задача по формам "Организовать хранение продажных цен деталей в разрезе типов цен (оптовые, розничные и т.д.) в документе «Расходная накладная» необходимо иметь возможность указывать тип цен, по которым осуществляется отпуск товара. В форме выбора деталей, для каждой детали, дополнительно необходимо отражать ее цену (согласно указанному в документе типу цен), а так же текущий остаток на складе. Склад, как и тип цен, указывается в шапке документа «Расходная накладная». При выборе детали в документ должна добавляться не только сама деталь, но и соответствующая цена."
Скачал твой вариант решения в форме обработке выбора номенклатуры в методе ПриСозданииНаСервере, ты
присваиваешь параметрам списка из переменной Параметры, но вопрос где инициализируется переменная Параметры?
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Список.Параметры.УстановитьЗначениеПараметра("Дата", Параметры.Дата);
Список.Параметры.УстановитьЗначениеПараметра("Склад", Параметры.Склад);
Список.Параметры.УстановитьЗначениеПараметра("ТипЦен", Параметры.ТипЦен);
КонецПроцедуры
Обычно это из процедуры ОткрытьФорму мы указываем как одну из ее переменных, но в примере, открытие формы делается платформой, нет такого кода.
Я так и не догнал откуда в нее попадают данные, подскажи пожалуйста как они попадают в метод ПриСозданииНаСервере?
Думал, что может платформа сама берет все реквизиты из родительской формы, добавил свой реквизит, но он не отобразился!
-
этой элементарной техники не в одном решении тут . сам леприкон
Посмотрел два последних решения, в обоих используется новая, разве что с небольшими ошибками. Смотрите внимательней, либо приводите конкретику, что не так. А то наспамили во всех ветках, "агрите прохожих" :D, а адекватных постов от вас почти нет.
-
https://forum.chistov.pro/index.php?action=profile;u=12564
По ПР. Из условия задачи получается, что в период отпуска ФиксСумма тоже выплачивается. То есть отпуском она не замещается! Значит действительно для нее план расчета не нужен.
-
Вопрос для Clition задача по формам "Организовать хранение продажных цен деталей в разрезе типов цен (оптовые, розничные и т.д.) в документе «Расходная накладная» необходимо иметь возможность указывать тип цен, по которым осуществляется отпуск товара. В форме выбора деталей, для каждой детали, дополнительно необходимо отражать ее цену (согласно указанному в документе типу цен), а так же текущий остаток на складе. Склад, как и тип цен, указывается в шапке документа «Расходная накладная». При выборе детали в документ должна добавляться не только сама деталь, но и соответствующая цена."
Скачал твой вариант решения в форме обработке выбора номенклатуры в методе ПриСозданииНаСервере, ты
присваиваешь параметрам списка из переменной Параметры, но вопрос где инициализируется переменная Параметры?
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Список.Параметры.УстановитьЗначениеПараметра("Дата", Параметры.Дата);
Список.Параметры.УстановитьЗначениеПараметра("Склад", Параметры.Склад);
Список.Параметры.УстановитьЗначениеПараметра("ТипЦен", Параметры.ТипЦен);
КонецПроцедуры
Обычно это из процедуры ОткрытьФорму мы указываем как одну из ее переменных, но в примере, открытие формы делается платформой, нет такого кода.
Я так и не догнал откуда в нее попадают данные, подскажи пожалуйста как они попадают в метод ПриСозданииНаСервере?
Думал, что может платформа сама берет все реквизиты из родительской формы, добавил свой реквизит, но он не отобразился!
Вопрос снят!
-
У многих в задаче по формам ошибка, при добавлении новой строки в тч Расходная накладная, строка не сохраняется. Данные сохраняются, если только уже в веденной строке делать выбор.
Решение: Нужно для элемента формы - список номенклатуры инициализировать редактирование строки методом ЗакончитьРедактированиеСтроки, по умолчанию, когда стандартная обработка ложь, он отменяет редактирование. Если данный метод имеет значение Истина, то происходит отмена редактирования строки.
В СписокНоменклатурыНоменклатураОбработкаВыбора пропишите: Элементы.СписокНоменклатуры.ЗакончитьРедактированиеСтроки(Ложь);
-
Просьба посмотреть мое решение 6 билета.
Сделал ОУ+БУ+СПР+УФ+БП полный комплект)
По СПР был вопрос - брать в расчете отпуска норму дней или фактически отработанные дни в базовом периоде? Сделал через норму дней в базе. Правильно ли это?
Регистрацию перерасчета сделал в модуле документа ОперацияБух, т.к. другого документа, которым можно сделать данную проводку, в задаче нет.
-
Просьба посмотреть мое решение 6 билета.
Сделал ОУ+БУ+СПР+УФ+БП полный комплект)
По СПР был вопрос - брать в расчете отпуска норму дней или фактически отработанные дни в базовом периоде? Сделал через норму дней в базе. Правильно ли это?
Регистрацию перерасчета сделал в модуле документа ОперацияБух, т.к. другого документа, которым можно сделать данную проводку, в задаче нет.
Решение не смотрел, но перерасчет нужно делать в модуле набора записей регистра бухгалтерии.
-
Попался сегодня этот билет. Тоже интересует, сдавали ли в последнее время с решением, где составы стеллажей организованы на РС с измерением Деталь и ресурсами Стеллаж, Количество?
-
Попался сегодня этот билет. Тоже интересует, сдавали ли в последнее время с решением, где составы стеллажей организованы на РС с измерением Деталь и ресурсами Стеллаж, Количество?
на 27 странице есть решение от ИнГор, ему на экзамене попались задачи ОУ из 6, БУХ из 3 и СПР из 6 билетов. Его решение беру за пример. Уникальность деталей контролирует в модуле набора записей Регистра Сведений СоставСтеллажей. Измерения Стеллаж, Деталь. Ресурс Количество. А как вы реализовали данную задачу? Задачи все из 6 билета или разные были? как реализовали СПР? Как реализовали условие "Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров."
-
на 27 странице есть решение от ИнГор, ему на экзамене попались задачи ОУ из 6, БУХ из 3 и СПР из 6 билетов. Его решение беру за пример. Уникальность деталей контролирует в модуле набора записей Регистра Сведений СоставСтеллажей. Измерения Стеллаж, Деталь. Ресурс Количество. А как вы реализовали данную задачу? Задачи все из 6 билета или разные были? как реализовали СПР? Как реализовали условие "Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров."
Экзамен сдала )) Контроль уникальности деталей не программировала специально. Реализовала через хранение в РС (измерение "Деталь", ресурс "Количество" и реквизит "Стеллаж"). Условие "Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров." не реализовывала. В пояснительной записке сослалась на текст из задания: "Считать, что после расчета сумма оплат корректировке не подлежит." Русским языком написано, и, считаю, что это условие противоречит последующему. Если необходимо реализовывать перерасчет при изменении сумм оплат, то пусть уберут данное предложение.
Из 6 билета были задачи по ОП и СПР, БУ - из 3-го билета. Задача по бизнесс-процессам не знаю, из какого (для меня нет особой разницы)
-
Экзамен сдала )) Контроль уникальности деталей не программировала специально. Реализовала через хранение в РС (измерение "Деталь", ресурс "Количество" и реквизит "Стеллаж"). Условие "Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров." не реализовывала. В пояснительной записке сослалась на текст из задания: "Считать, что после расчета сумма оплат корректировке не подлежит." Русским языком написано, и, считаю, что это условие противоречит последующему. Если необходимо реализовывать перерасчет при изменении сумм оплат, то пусть уберут данное предложение.
Из 6 билета были задачи по ОП и СПР, БУ - из 3-го билета. Задача по бизнесс-процессам не знаю, из какого (для меня нет особой разницы)
Поздравляю !!! на какую оценку сдали? били ли ошибки ? не могли ли выложить совой билет интересно как решен СПР из из 6 билета
-
Спасибо!!
Да, были недочеты: "В расходной накладной наложена избыточная блокировка, используется менее эффективная методика проведения."
Про избыточную блокировку я и сама догадалась почти сразу после сдачи. Заблокировала все остатки по складу, а можно было, используя менеджер временных таблиц, выгрузить в тз перечень деталей с учетом комплектов и заблокировать только по указанным деталям.
Списывала по старой методике: обходом по запросу. Теперь буду знать, что оптимальней сначала списать, а потом смотреть на отрицательные остатки.
-
Вечер добрый.
Сдавал 17.10.2018 г. удаленно в г. Краснодаре.
Попался 6 билет. Полностью совпадает с актуальными, с изменениями.
Полностью сделал ОУ, БУ, а вот в СПР готово все, кроме перерасчетов по РБ.(В посте выше вижу, что человек сдал, который намерено это не делал, но я комментариев по этому поводу не оставлял, посему думаю снимут балы).
И не доделал БП, к своему стыду.(Мало времени уделял ему во время подготовки.)
Времени было достаточно. Сложно представить, что его может не хватить(только разве если задачи впервые в глаза видишь).
Было несколько глюков в процессе. Одна критическая ошибка базы, которая лечилась режимом совместимости). Неудобная клавиатура, у которой залипал Ctrl.
Пока не буду писать как решал, так как оценку жду. Да и кажется, что не дотяну до оценки в 3 балла.
Так как за БП сразу минус балл. И за отсутствие перерасчета по РБ будет или минус балл, или хотя бы - 0,5.
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
Решено не правильно. Комментировать не буду, слишком много недочетов.
Сам только решил эту задачу. Смотри как я решал.
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
Решено не правильно. Комментировать не буду, слишком много недочетов.
Сам только решил эту задачу. Смотри как я решал.
Привет! У меня походу вообще какие-то билеты другие. Можешь скинуть ссылку, где ты брал? Или скинуть сюда сами билеты.
И, могу сказать точно, что СПР у тебя решен не правильно) "КоличествоДнейВПериоде = День(КонецМесяца(Ссылка.Дата));" - явно не то, что нужно
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
Решено не правильно. Комментировать не буду, слишком много недочетов.
Сам только решил эту задачу. Смотри как я решал.
Привет! У меня походу вообще какие-то билеты другие. Можешь скинуть ссылку, где ты брал? Или скинуть сюда сами билеты.
И, могу сказать точно, что СПР у тебя решен не правильно) "КоличествоДнейВПериоде = День(КонецМесяца(Ссылка.Дата));" - явно не то, что нужно
Это результат медитации над задачей))
Если серьезно, то это календарное время, так как написано, что отпуск календарный месяц. Календарное время можно считать без механизмов платформы.
Я вам писал уже про дополнения, вы дополнения читаете?
вот здесь
https://forum.chistov.pro/index.php?topic=2670.1140
Сообщение 1149 от Trevis
У меня такие же.
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
Решено не правильно. Комментировать не буду, слишком много недочетов.
Сам только решил эту задачу. Смотри как я решал.
Привет! У меня походу вообще какие-то билеты другие. Можешь скинуть ссылку, где ты брал? Или скинуть сюда сами билеты.
И, могу сказать точно, что СПР у тебя решен не правильно) "КоличествоДнейВПериоде = День(КонецМесяца(Ссылка.Дата));" - явно не то, что нужно
Это результат медитации над задачей))
Если серьезно, то это календарное время, так как написано, что отпуск календарный месяц. Календарное время можно считать без механизмов платформы.
Я вам писал уже про дополнения, вы дополнения читаете?
вот здесь
https://forum.chistov.pro/index.php?topic=2670.1140
Сообщение 1149 от Trevis
У меня такие же.
Дополнения читал
1) Билет 6.
БП.
1. Задача заменена задачей БП из билета 14.
У тебя вроде не эта задача решена)
2) СПР . Сумма оплат должна быть получена по данным бухгалтерского учета с использованием следующей проводки: Дт «Касса» - Кт «Покупатели» на сумму оплат. Считать, что после расчета сумма оплат корректировке не подлежит
У тебя создан регистр накопления.
3) Дни отпуска рассчитываются по пятидневному графику. Это значит не весь месяц. НУ а по поводу давать целый месяц или нет, можно по разному трактовать, я сделал, что можно давать частями, не думаю, что это ошибка.
4) Следует учесть, что данные об отпуске не могут вводиться в систему задним числом. У тебя не учтено.
5) Создать отчет «Перерасчеты зарплаты», в котором пользователь должен увидеть записи регистра расчета, которые возможно требуется пересчитать. Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров. - Не реализовано) Перерасчеты по буху довольно не просты)
6) В билете я не увидел ни слова про БизнесПроцессы. Там задача по УФ
7) Ну и док Операция не правильно сделан. С проведением...
8) Ошибка при запуске - ПользовательСистемы = Справочники.ФизическиеЛица.НайтиПоКоду(ИмяПользователя());
Я не прав по списку? =)
А какие у меня ошибки?
-
Всем привет! Прошу проверить решение билета)
Сделал за 4,3 часа. Надеюсь недочетов не много! Пишите, пожалуйста, если что не правильно сделано)
Решено не правильно. Комментировать не буду, слишком много недочетов.
Сам только решил эту задачу. Смотри как я решал.
Привет! У меня походу вообще какие-то билеты другие. Можешь скинуть ссылку, где ты брал? Или скинуть сюда сами билеты.
И, могу сказать точно, что СПР у тебя решен не правильно) "КоличествоДнейВПериоде = День(КонецМесяца(Ссылка.Дата));" - явно не то, что нужно
Это результат медитации над задачей))
Если серьезно, то это календарное время, так как написано, что отпуск календарный месяц. Календарное время можно считать без механизмов платформы.
Я вам писал уже про дополнения, вы дополнения читаете?
вот здесь
https://forum.chistov.pro/index.php?topic=2670.1140
Сообщение 1149 от Trevis
У меня такие же.
Дополнения читал
1) Билет 6.
БП.
1. Задача заменена задачей БП из билета 14.
У тебя вроде не эта задача решена)
2) СПР . Сумма оплат должна быть получена по данным бухгалтерского учета с использованием следующей проводки: Дт «Касса» - Кт «Покупатели» на сумму оплат. Считать, что после расчета сумма оплат корректировке не подлежит
У тебя создан регистр накопления.
3) Дни отпуска рассчитываются по пятидневному графику. Это значит не весь месяц. НУ а по поводу давать целый месяц или нет, можно по разному трактовать, я сделал, что можно давать частями, не думаю, что это ошибка.
4) Следует учесть, что данные об отпуске не могут вводиться в систему задним числом. У тебя не учтено.
5) Создать отчет «Перерасчеты зарплаты», в котором пользователь должен увидеть записи регистра расчета, которые возможно требуется пересчитать. Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров. - Не реализовано) Перерасчеты по буху довольно не просты)
6) В билете я не увидел ни слова про БизнесПроцессы. Там задача по УФ
7) Ну и док Операция не правильно сделан. С проведением...
8) Ошибка при запуске - ПользовательСистемы = Справочники.ФизическиеЛица.НайтиПоКоду(ИмяПользователя());
Я не прав по списку? =)
А какие у меня ошибки?
1. Задача про совещания. У меня такая же.
2. Да, в задании сказано что надо получать по данным бухгалтерского учета. Так как задача с не сразу понятными условиями, я немного поэкспериментировал и пытался сделать логически законченный вариант. Для экзамена лучше сделать документом "Операция" приход на субконто "Сотрудник".
3. Тут трактовать можно по разному. Сначала идет что у сотрудника отпуск один календарный месяц в году, а потом дни отпуска рассчитываются по пятидневному графику, я подумал что рассчитывается база дней по пятидневке. Ну можно так и так, но если реальную жизнь посмотреть, то наверно мой вариант более правдоподобен.
4. Этот пункт никак учитывать не надо. В этом пункте сказано, что просто вводиться не будет отпуск задним числом и все. Тут проверок делать не надо. Вот если бы было сказано что отпуск будет вводиться, тогда надо делать сторнирование.
5. Да перерасчетов нет. Но я если честно не планировал их делать на экзамене))
6. БП точно, тем, кому попался этот билет, у всех был БП.
7. Полностью согласен))
8. У меня все запускается.
Я когда смотрел твое решение, я открыл ОсновныеНачисления, увидел там фикс сумму, и дальше смотреть не стал, но надо было еще настройки посмотреть....
Поэтому я и решил что не правильно. Если присмотреться, то вы просто в доп нач отпуск записали а фикс сумму в осн нач. Но флажки поставили правильно. Только базы у Осн нач нет. Ну я бы еще и в дом начислениях поставил зависимость по регистратору, а не по периоду.
-
1. Задача про совещания. У меня такая же.
2. Да, в задании сказано что надо получать по данным бухгалтерского учета. Так как задача с не сразу понятными условиями, я немного поэкспериментировал и пытался сделать логически законченный вариант. Для экзамена лучше сделать документом "Операция" приход на субконто "Сотрудник".
3. Тут трактовать можно по разному. Сначала идет что у сотрудника отпуск один календарный месяц в году, а потом дни отпуска рассчитываются по пятидневному графику, я подумал что рассчитывается база дней по пятидневке. Ну можно так и так, но если реальную жизнь посмотреть, то наверно мой вариант более правдоподобен.
4. Этот пункт никак учитывать не надо. В этом пункте сказано, что просто вводиться не будет отпуск задним числом и все. Тут проверок делать не надо. Вот если бы было сказано что отпуск будет вводиться, тогда надо делать сторнирование.
5. Да перерасчетов нет. Но я если честно не планировал их делать на экзамене))
6. БП точно, тем, кому попался этот билет, у всех был БП.
7. Полностью согласен))
8. У меня все запускается.
Я когда смотрел твое решение, я открыл ОсновныеНачисления, увидел там фикс сумму, и дальше смотреть не стал, но надо было еще настройки посмотреть....
Поэтому я и решил что не правильно. Если присмотреться, то вы просто в доп нач отпуск записали а фикс сумму в осн нач. Но флажки поставили правильно. Только базы у Осн нач нет. Ну я бы еще и в дом начислениях поставил зависимость по регистратору, а не по периоду.
[/quote]
1) Про какие совещания?
14 билет БУ - Операция сборки комплекта оформляется в системе с помощью документа «Сборка». В шапке этого документа указывается комплект, склад с которого происходит списание и склад на который приходуется готовая продукция. Вот часть текста.
6) Может быть просто тем кто сдавал, попадалась часть из 6 билета, а бп из другого. По умолчанию тут УФ же
8) он запускается, но не найдет никогда физлицо, так как по коду поиск)
-
1) Про какие совещания?
14 билет БУ - Операция сборки комплекта оформляется в системе с помощью документа «Сборка». В шапке этого документа указывается комплект, склад с которого происходит списание и склад на который приходуется готовая продукция. Вот часть текста.
6) Может быть просто тем кто сдавал, попадалась часть из 6 билета, а бп из другого. По умолчанию тут УФ же
8) он запускается, но не найдет никогда физлицо, так как по коду поиск)
БП -бизнес процесс.
БУ - бухгалтерский учет.
БУ в 6 билете из билета 3, по последним данным от сдающих))
-
8) он запускается, но не найдет никогда физлицо, так как по коду поиск)
Почему он не найдет? Там все ищет и адресация работает согласно заданию.
В заголовке же пишет списка задач, при старте кого он нашел))
-
1) Про какие совещания?
14 билет БУ - Операция сборки комплекта оформляется в системе с помощью документа «Сборка». В шапке этого документа указывается комплект, склад с которого происходит списание и склад на который приходуется готовая продукция. Вот часть текста.
6) Может быть просто тем кто сдавал, попадалась часть из 6 билета, а бп из другого. По умолчанию тут УФ же
8) он запускается, но не найдет никогда физлицо, так как по коду поиск)
БП -бизнес процесс.
БУ - бухгалтерский учет.
БУ в 6 билете из билета 3, по последним данным от сдающих))
Перепутал, блин, придется переделывать))
-
Подскажите, как разруливаются логические конфликты между микрозадачами одного билета?
Например, в Билете 6 из Актуальных билетов в Опер. учете при списании стеллажа нужно списывать его комплектующие, а в Бух. учете - контроль достаточности остатков, который не даст списать ни один сборный стеллаж, поскольку как таковые номенклатуры стеллажей на приход не ставятся, а если и будут куплены, то уже по Опер. учету не спишутся и зависнут на остатках ОУ.
Плюс Склад в БУ в ТЧ, а в ОУ в шапке в Приходной накладной.
Ну и в требованиях - штраф два балла за использование разных объектов (документов, например) для разных микрозадач.
-
Подскажите, как разруливаются логические конфликты между микрозадачами одного билета?
Например, в Билете 6 из Актуальных билетов в Опер. учете при списании стеллажа нужно списывать его комплектующие, а в Бух. учете - контроль достаточности остатков, который не даст списать ни один сборный стеллаж, поскольку как таковые номенклатуры стеллажей на приход не ставятся, а если и будут куплены, то уже по Опер. учету не спишутся и зависнут на остатках ОУ.
Плюс Склад в БУ в ТЧ, а в ОУ в шапке в Приходной накладной.
Ну и в требованиях - штраф два балла за использование разных объектов (документов, например) для разных микрозадач.
Новые документы для бухучета создавать ни в коем случае не надо.
Если на экзамене будут конфликты усливий задач по БУ и ОУ, то сделайте в документе два реквизита булево "БУ" и "ОУ". Если установлен флаг ОУ - то при проведении выполняются алгоритмы ОУ, если БУ - то алгоритмы БУ.
-
Подскажите, как разруливаются логические конфликты между микрозадачами одного билета?
Например, в Билете 6 из Актуальных билетов в Опер. учете при списании стеллажа нужно списывать его комплектующие, а в Бух. учете - контроль достаточности остатков, который не даст списать ни один сборный стеллаж, поскольку как таковые номенклатуры стеллажей на приход не ставятся, а если и будут куплены, то уже по Опер. учету не спишутся и зависнут на остатках ОУ.
Плюс Склад в БУ в ТЧ, а в ОУ в шапке в Приходной накладной.
Ну и в требованиях - штраф два балла за использование разных объектов (документов, например) для разных микрозадач.
Новые документы для бухучета создавать ни в коем случае не надо.
Если на экзамене будут конфликты усливий задач по БУ и ОУ, то сделайте в документе два реквизита булево "БУ" и "ОУ". Если установлен флаг ОУ - то при проведении выполняются алгоритмы ОУ, если БУ - то алгоритмы БУ.
Да, я уже пошарил там и сям, надергал примеров - так и делаю (с флагами). Еще, возможно, в "боевом" билете может и не оказаться конфликта - микрозадачи же перемешивают (т.е. разные темы БУ и ОУ могут попасться, которые "не подерутся"). Спасибо за ответ.
-
Добрый день!
Ребята, про аргументы, делать
ли Автомобиль измерением или реквизитом
в РР ОсновныеНачисления - здесь много было сказано.
А какие аргументы для РР ДополнительныеНачисления?
Измерением делать автомобиль или реквизитом?
-
Подскажите, как разруливаются логические конфликты между микрозадачами одного билета?
Например, в Билете 6 из Актуальных билетов в Опер. учете при списании стеллажа нужно списывать его комплектующие, а в Бух. учете - контроль достаточности остатков, который не даст списать ни один сборный стеллаж, поскольку как таковые номенклатуры стеллажей на приход не ставятся, а если и будут куплены, то уже по Опер. учету не спишутся и зависнут на остатках ОУ.
Плюс Склад в БУ в ТЧ, а в ОУ в шапке в Приходной накладной.
Ну и в требованиях - штраф два балла за использование разных объектов (документов, например) для разных микрозадач.
Новые документы для бухучета создавать ни в коем случае не надо.
Если на экзамене будут конфликты усливий задач по БУ и ОУ, то сделайте в документе два реквизита булево "БУ" и "ОУ". Если установлен флаг ОУ - то при проведении выполняются алгоритмы ОУ, если БУ - то алгоритмы БУ.
Да, я уже пошарил там и сям, надергал примеров - так и делаю (с флагами). Еще, возможно, в "боевом" билете может и не оказаться конфликта - микрозадачи же перемешивают (т.е. разные темы БУ и ОУ могут попасться, которые "не подерутся"). Спасибо за ответ.
ДУмаю, их один раз перемещали и больше не перемешивают. Я когда сдавал, билет выдали уже значительной степени измятости, а в указаниях написано, что пометок не делать, а если они сделаны ручкой - игнорировать.
-
Добрый день!
Ребята, про аргументы, делать
ли Автомобиль измерением или реквизитом
в РР ОсновныеНачисления - здесь много было сказано.
А какие аргументы для РР ДополнительныеНачисления?
Измерением делать автомобиль или реквизитом?
На мой взгляд фраза "возможен обмен автомобилями между водителями" соответствует фразе из других билетов "возможно совместительство". Поэтому делать в измерениях. Хотя сложно себе представить сотрудника, который одновременно управляет двумя автомобилями (видимо предполагается, что в течение дня он возит обычных людей на дешевой машине, а директора - на представительской). Если сдаете очно - лучше явно у препода спросить, может ли в течение одного дня быть несколько машин у сотрудника.
-
eiffil, Вы говорите про РР "ОсновныеНачисления".
Я спрашивал про ДополнительныеНачисления.
-
eiffil, Вы говорите про РР "ОсновныеНачисления".
Я спрашивал про ДополнительныеНачисления.
По словам Белоусова, ДополнительныеНачисления нужно делать аналогично ОсновнымНачислениям. Если в одном реквизит, то и в другом.
-
eiffil, Вы говорите про РР "ОсновныеНачисления".
Я спрашивал про ДополнительныеНачисления.
По словам Белоусова, ДополнительныеНачисления нужно делать аналогично ОсновнымНачислениям. Если в одном реквизит, то и в другом.
Да, верно. Т.к. совместительство - оно же не зависит от регистра. поэтому подход одинаковый в данном случае
-
eiffil, Вы говорите про РР "ОсновныеНачисления".
Я спрашивал про ДополнительныеНачисления.
По словам Белоусова, ДополнительныеНачисления нужно делать аналогично ОсновнымНачислениям. Если в одном реквизит, то и в другом.
Тут я бы уточнил, что это касается измерений. Реквизиты не обязательно совпадут- а зачастую они разные. Ведь в основных начислениях есть период действия и зачастую график работы.
Автомобиль нужно делать измерением, как сказал eiffil. И это правда похоже на "совместительство".
Я сделал в у автомобиля реквизит График работы. Таким образом реализуется условие, что у каждого автомобиля свой график работы.
-
Подскажите, особенно те, кому при сдаче попадала задача ОУ из этого билета, что значит формулировка "Необходимо обеспечить уникальность деталей, т.е. одна и та же деталь не может относиться к разным стеллажам."? т.е. номенклатура "Болт" или "Гайка" может принадлежать только одному стеллажу?
и контроль уникальности реализовывается при вводе комплектации нового стеллажа?
Сам "Стеллаж" при этом - номенклатурная позиция (приобретаемая, собственного производства)? Стеллаж тоже хранится на складе и списывается ?
-
Подскажите, особенно те, кому при сдаче попадала задача ОУ из этого билета, что значит формулировка "Необходимо обеспечить уникальность деталей, т.е. одна и та же деталь не может относиться к разным стеллажам."? т.е. номенклатура "Болт" или "Гайка" может принадлежать только одному стеллажу?
и контроль уникальности реализовывается при вводе комплектации нового стеллажа?
Сам "Стеллаж" при этом - номенклатурная позиция (приобретаемая, собственного производства)? Стеллаж тоже хранится на складе и списывается ?
Да, одна деталь может относиться только к одному стеллажу. Решается просто: деталь в измерение регистра сведений, стеллаж в ресурсы. И деталь и стеллаж (собственного производства) — номенклатурные позиции и соответственно в расходной накладной может списываться и то и то. Но остатки у нас в разрезе деталей, поэтому при проведении расходной накладной надо будет разбирать стеллажи на детали.
-
Да, одна деталь может относиться только к одному стеллажу. Решается просто: деталь в измерение регистра сведений, стеллаж в ресурсы. И деталь и стеллаж (собственного производства) — номенклатурные позиции и соответственно в расходной накладной может списываться и то и то. Но остатки у нас в разрезе деталей, поэтому при проведении расходной накладной надо будет разбирать стеллажи на детали.
Да, спасибо :) Реализовал уже вариант, когда стеллаж в реквизите. Зачем он в ресурсе? Стеллаж только номенклатура, количественно его не существует.
-
Да, одна деталь может относиться только к одному стеллажу. Решается просто: деталь в измерение регистра сведений, стеллаж в ресурсы. И деталь и стеллаж (собственного производства) — номенклатурные позиции и соответственно в расходной накладной может списываться и то и то. Но остатки у нас в разрезе деталей, поэтому при проведении расходной накладной надо будет разбирать стеллажи на детали.
Да, спасибо :) Реализовал уже вариант, когда стеллаж в реквизите. Зачем он в ресурсе? Стеллаж только номенклатура, количественно его не существует.
Да разницы нет.
-
Да, одна деталь может относиться только к одному стеллажу. Решается просто: деталь в измерение регистра сведений, стеллаж в ресурсы. И деталь и стеллаж (собственного производства) — номенклатурные позиции и соответственно в расходной накладной может списываться и то и то. Но остатки у нас в разрезе деталей, поэтому при проведении расходной накладной надо будет разбирать стеллажи на детали.
Да, спасибо :) Реализовал уже вариант, когда стеллаж в реквизите. Зачем он в ресурсе? Стеллаж только номенклатура, количественно его не существует.
Для регистра сведений нет разницы между ресурсом и реквизитом (кроме очень ограниченного списка задач, типа графиков работ для регистров расчета, где можно выбирать только ресурсы регистра).
-
Да, одна деталь может относиться только к одному стеллажу. Решается просто: деталь в измерение регистра сведений, стеллаж в ресурсы. И деталь и стеллаж (собственного производства) — номенклатурные позиции и соответственно в расходной накладной может списываться и то и то. Но остатки у нас в разрезе деталей, поэтому при проведении расходной накладной надо будет разбирать стеллажи на детали.
Да, спасибо :) Реализовал уже вариант, когда стеллаж в реквизите. Зачем он в ресурсе? Стеллаж только номенклатура, количественно его не существует.
Для регистра сведений нет разницы между ресурсом и реквизитом (кроме очень ограниченного списка задач, типа графиков работ для регистров расчета, где можно выбирать только ресурсы регистра).
В механизме нет, но логическая разница есть, насколько я понимаю: реквизиты - это дополнительные данные, а ресурсы - те данные, ради которых регистр создан.
Т.е. пример реквизита - "примечание".
Вот цитата с мисты: " dimoff 4 - 11.02.09 - 13:13 (2) Только логический. В ресурсы нужно пихать то что является результатом, а в реквизиты то что характеризует саму запись...."
И вот ещё очень развёрнутое объяснение:
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=540995&threadtype=0 (http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=540995&threadtype=0)
сообщение номер 540995
Только вот в результате автор вопроса вроде так и не понял сути объяснения.
-
Всем доброго дня!
Кто решил условие о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров?
Может скажете куда копать.
Мое предположение: реализовать с помощью отчета (прочитать текущую сумму и сравнить с суммой по которой был расчет (предварительно хранить в доп.нач. сумму для расчета))
-
Всем доброго дня!
Кто решил условие о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров?
Может скажете куда копать.
Мое предположение: реализовать с помощью отчета (прочитать текущую сумму и сравнить с суммой по которой был расчет (предварительно хранить в доп.нач. сумму для расчета))
В модуле набора записей нужно анализировать необходимость перерасчета и создавать новые записи перерасчета.
-
Всем доброго дня!
Кто решил условие о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров?
Может скажете куда копать.
Мое предположение: реализовать с помощью отчета (прочитать текущую сумму и сравнить с суммой по которой был расчет (предварительно хранить в доп.нач. сумму для расчета))
В модуле набора записей нужно анализировать необходимость перерасчета и создавать новые записи перерасчета.
Уточню Модуль набора записей регистра бухгалтерии
-
Доброго времени суток. Так и не смог объяснить для себя зачем делать измерение "Автомобиль" в РР. Сделал автомобиль реквизитом физлица, что удовлетворяет условию: "Сотрудники работают на автомобилях предприятия, поэтому возможен обмен автомобилями между водителями". И реквизитом графика, что соответствует: "Все сотрудники работают по графику работы, установленному для каждого автомобиля отдельно.".
Еще один момент - чтобы сделать перерасчеты для РР ДН, нужно в ПВР ДН установить зависимость от базы (хотя в расчетах база нигде не используется), соответственно настраивается измерение. Будет ли подобное решение зачтено за ошибку? Или возможно я что-то делаю неправильно.
Во вложении мое решение, буду рад обратной связи.
-
Уникальность стеллажей реализуется с помощью ПВХ, инфа из проверенного источника, но такого решения к сожалею на этом форуме на сколько я знаю нет, поэтому придется разбирать ПВХ. Еще он делается по подобию примера из книжки Практическое пособие разработчика Радченко.
-
Уникальность стеллажей реализуется с помощью ПВХ, инфа из проверенного источника, но такого решения к сожалею на этом форуме на сколько я знаю нет, поэтому придется разбирать ПВХ. Еще он делается по подобию примера из книжки Практическое пособие разработчика Радченко.
Не морочьте голову ни себе не другим. Регистр сведений "Состав стеллажей", Измерение - Номенклатура, Ресурс - Количество Реквизит - Стеллаж.
-
Уникальность стеллажей реализуется с помощью ПВХ, инфа из проверенного источника, но такого решения к сожалею на этом форуме на сколько я знаю нет, поэтому придется разбирать ПВХ. Еще он делается по подобию примера из книжки Практическое пособие разработчика Радченко.
Белоусов в курсах проговаривается об отсутствии ПВХ в задачах ОУ на экзамене... Так что видимо рабочим вариантом остается распространенный РС, тем более что уникальность детали вполне обеспечивает структура, описанная Товарищем :)
-
как лучше сделать всё таки комплектацию добавить в справочник номенклатура, или через РС делать?
-
Решена только задача по ОУ.
Просьба прокомментировать решение.
-
Решена только задача по ОУ.
Просьба прокомментировать решение.
Я бы сказал, что процедура при записи РС СоставСтелажей только отнимет время на экзамене, хотя и не будет, скорее всего являться ошибкой, хотя это лишний запрос в БД. По факту РС сам будет контролировать уникальность если деталь будет измерением, а стеллаж ресурсом. Да, такое распределение с точки зрения человека выглядит нелогичным, но с точки зрения платформы работает отлично.
По поводу обработки проведения. В целом там трудно ошибиться, есть пара моментов, которые непонятны для меня, возможно вы сможете их аргументировать:
1) Порядок строк, в которых вы сначала записываете регистр, а только потом его блокируете для изменения вызывает определенные вопросы.
2) Проверка на NULL во втором запросе не имеет особого смысла, т.к. у вы выбираете все строки где КоличествоОстаток<0, мелочь, конечно, но в глаза бросается.
3) Почему условие ВТ ОстаткиНоменклатурыОстатки на склад вы наложили, а на номенклатуру нет?
4) Не уверен, что целесообразно заморачиваться с таким сообщением пользователю, этого не было в задании. Не ошибка, конечно, но время потратите на экзамене. Разумнее использовать ф-ию сообщить. А если хотите все по красоте, то почему тогда не эксепшены?
-
Ребят и еще есть вопрос, по СПР, смотрю уже не первое решение, если требуется получить что-то вроде "Сумма продаж подразделения за прошлый месяц" или "Сумма оплат покупателей за прошлый период", используется установление периода от даты документа НачислениеЗарплаты. Что то вроде:
Запрос.УстановитьПараметр("НачалоПред", НачалоМесяца(НачалоМесяца(Дата)-1));
Запрос.УстановитьПараметр("КонецПред", НачалоМесяца(Дата)-1);
Это не является ошибкой? Я про то, что если я захочу документом, например, за Март рассчитать Январьские зарплаты. Сумма продаж возьмется за Февраль, что не совсем корректно.
-
Ребят и еще есть вопрос, по СПР, смотрю уже не первое решение, если требуется получить что-то вроде "Сумма продаж подразделения за прошлый месяц" или "Сумма оплат покупателей за прошлый период", используется установление периода от даты документа НачислениеЗарплаты. Что то вроде:
Запрос.УстановитьПараметр("НачалоПред", НачалоМесяца(НачалоМесяца(Дата)-1));
Запрос.УстановитьПараметр("КонецПред", НачалоМесяца(Дата)-1);
Это не является ошибкой? Я про то, что если я захочу документом, например, за Март рассчитать Январьские зарплаты. Сумма продаж возьмется за Февраль, что не совсем корректно.
Многие не делают дополнительный реквизит ПериодРегистрации в документе, считаю Дату документа периодом регистрации. А период регистрации - это и есть месяц расчета. Поэтому вводя документ в марте рассчитывают именно март.
Так что установка параметров более чем логична.
Не очень оптимально, правда. Ибо два раза рассчитывается одна и та же операция НачалоМесяца(Дата)
Я бы заменил код
Запрос.УстановитьПараметр("НачалоПред", НачалоМесяца(НачалоМесяца(Дата)-1));
Запрос.УстановитьПараметр("КонецПред", НачалоМесяца(Дата)-1);на более оптимальный и понятный, пусть и с дополнительной переменной:
ПериодРегистрации = НачалоМесяца (Дата);
Запрос.УстановитьПараметр("НачалоПред", ДобавитьМесяц(ПериодРегистрации, -1));
Запрос.УстановитьПараметр("КонецПред", ПериодРегистрации - 1);Но в рамках экзамена, конечно, с этим можно не заморачиваться.
-
Михаил, спасибо за ваши ответы и по этому поводу и по поводу актуальных билетов)
-
Решена только задача по ОУ.
Просьба прокомментировать решение.
Я бы сказал, что процедура при записи РС СоставСтелажей только отнимет время на экзамене, хотя и не будет, скорее всего являться ошибкой, хотя это лишний запрос в БД. По факту РС сам будет контролировать уникальность если деталь будет измерением, а стеллаж ресурсом. Да, такое распределение с точки зрения человека выглядит нелогичным, но с точки зрения платформы работает отлично.
По поводу обработки проведения. В целом там трудно ошибиться, есть пара моментов, которые непонятны для меня, возможно вы сможете их аргументировать:
1) Порядок строк, в которых вы сначала записываете регистр, а только потом его блокируете для изменения вызывает определенные вопросы.
2) Проверка на NULL во втором запросе не имеет особого смысла, т.к. у вы выбираете все строки где КоличествоОстаток<0, мелочь, конечно, но в глаза бросается.
3) Почему условие ВТ ОстаткиНоменклатурыОстатки на склад вы наложили, а на номенклатуру нет?
4) Не уверен, что целесообразно заморачиваться с таким сообщением пользователю, этого не было в задании. Не ошибка, конечно, но время потратите на экзамене. Разумнее использовать ф-ию сообщить. А если хотите все по красоте, то почему тогда не эксепшены?
Спасибо за просмотр решения.
По поводу регистра. Изначально была мысль делать Измерение Деталь, Ресурсы: Стеллаж, Количество. Но нашел в ветке об этом регистре такое замечание:
Результат экзамена:
ОУ: неверно организовано хранение информации о составе стеллажа, регистры предназначены для быстрого получения информации по измерениям, а не ресурсам
1. Порядок строк должен быть именно такой. Запись относится к первому блоку, когда мы записываем данные в регистр. Далее нам надо записи заблокировать для чтения.
2. При левом соединении всегда привычка ставить ЕстьNULL. Насколько я знаю, на экзамене тоже важно ее именно ставить.
3. Проверил. Есть условие и на склад и на номенклатуру.
4. Да, это делать не нужно. Это я сделал, увидев в другом билете такое задание на управляемые формы, вот и решил потренироваться.
-
Решена только задача по ОУ.
Просьба прокомментировать решение.
1) Порядок строк, в которых вы сначала записываете регистр, а только потом его блокируете для изменения вызывает определенные вопросы.
Спасибо за просмотр решения.
1. Порядок строк должен быть именно такой. Запись относится к первому блоку, когда мы записываем данные в регистр. Далее нам надо записи заблокировать для чтения.
Соглашусь с предыдущим оратором)
Строки
Движения.ОстаткиНоменклатуры.Записать();
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;В той последовательности, в какой они расположены в модуле - не имеют смысла. Второй строкой Вы отключаете разделитель итогов, но сработает это лишь при записи набора до конца транзакции. При Вашей же последовательности не сработает вовсе. Строки нужны поменять местами.
-
Решена только задача по ОУ.
Просьба прокомментировать решение.
1) Порядок строк, в которых вы сначала записываете регистр, а только потом его блокируете для изменения вызывает определенные вопросы.
Спасибо за просмотр решения.
1. Порядок строк должен быть именно такой. Запись относится к первому блоку, когда мы записываем данные в регистр. Далее нам надо записи заблокировать для чтения.
Соглашусь с предыдущим оратором)
Строки
Движения.ОстаткиНоменклатуры.Записать();
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;В той последовательности, в какой они расположены в модуле - не имеют смысла. Второй строкой Вы отключаете разделитель итогов, но сработает это лишь при записи набора до конца транзакции. При Вашей же последовательности не сработает вовсе. Строки нужны поменять местами.
Да, ошибку свою понял, спасибо.
-
Насчет этого: "По поводу регистра. Изначально была мысль делать Измерение Деталь, Ресурсы: Стеллаж, Количество. Но нашел в ветке об этом регистре такое замечание:
Результат экзамена:
ОУ: неверно организовано хранение информации о составе стеллажа, регистры предназначены для быстрого получения информации по измерениям, а не ресурсам"
Было бы время - занялся проверкой, мне почему-то кажется, что дополнительный запрос даже при большом количестве записей отработает медленнее чем механизм платформы, пусть и с отбором по ресурсу.
Но раз так хотят на экзамене - нужно будет учесть)
-
Внесу свежую струю :)
По поводу вечерних часов.
Самый простой, быстрый и правильный вариант (с точки зрения цифр) считать вечерние часы вместе с окладом и командировкой. ЧасСтавка*Факт+ЧасСтавка*0,5*ФактВечер.
Но как к этому относятся экзаменаторы я не знаю.
Вариант расчета по базе в основных начислениях, как тут попадаются решения, я считаю неверным. Т.к. неизвестен график. В задаче условие про разные графики. Можно полмесяца работать по шестидневке, а половину в командировке по пятидневке. Расчет вечерних часов по базе тогда будет неверным.
Предлагаю свой вариант решения. Вечерние часы в доп начислениях, ФактВечер в ресурсах основных начислений. ВидыРасчета для командировки и оклада разные (ВечерниеЧасыОклад и ВечерниеЧасыКомандировка), но функция одна и таже. (разные базы)
Для примера ввел еще один вид расчета, просто ВечерниеЧасы, с тем же алгоритмом (база командировка и оклад) - аналог примеров решений. И посчитал оклад по шестидневке, а командировку по пятидневке. Можно увидеть, что общий расчет подвирает :)
Решение красивое, но очень долгое. Вот не знаю как быть с экзаменом :)
P.S. Ошибся билетом, перевыложу в третий. сорри
-
Решил только ОУ. Оказался самым сложным для меня, если брать с 1 по 6 только по ОУ.
-
Гуру кто сдал, подскажите по Оперативному учету (стелажи),
1) уникальность деталей обеспечивается тупо структурой регистра сведений когда деталь в измерение а комплект в ресурс? других телодвижений на этот счет не нужно делать? ну там ограничения подборов например?
2) По проведению в расходной, я так понял нужно разобрать стелаж на детали потом все кучей провести (по новой методике) а потом смотрим остатки и отменяем если минус?
-
Гуру кто сдал, подскажите по Оперативному учету (стелажи),
1) уникальность деталей обеспечивается тупо структурой регистра сведений когда деталь в измерение а комплект в ресурс? других телодвижений на этот счет не нужно делать? ну там ограничения подборов например?
2) По проведению в расходной, я так понял нужно разобрать стелаж на детали потом все кучей провести (по новой методике) а потом смотрим остатки и отменяем если минус?
сдал, но первым билетом. Этот при подготовке решал так же, как спрашиваешь :) - уникальность только измерением, проведение - разбор и контроль по новой, так ка нет себестоимости
-
Народ извините за избитый вопрос по БУ, лазил по ветке но так и не увидел чтобы пришли к общему мнению по формулировке "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", Правильно ли я понимаю что склад не учитываем , если несколько позиций одного товара по разным складам было в партии то суммируем если одна то берем эту сумму позиции ? видел варианты решений с двумя ресурсами количествосклад количествоПартия, есть подтверждения что на экзамене принимают его?
-
Народ извините за избитый вопрос по БУ, лазил по ветке но так и не увидел чтобы пришли к общему мнению по формулировке "Себестоимость товара рассчитывается в разрезе партий поступления этого товара.", Правильно ли я понимаю что склад не учитываем , если несколько позиций одного товара по разным складам было в партии то суммируем если одна то берем эту сумму позиции ? видел варианты решений с двумя ресурсами количествосклад количествоПартия, есть подтверждения что на экзамене принимают его?
Если интересует мнение сдавшего не этот билет - Количество одно (как ресурс), себестоимость только по партиям (без складов).
-
Да это самый простой вариант конечно, но сдается склад в тч не просто так запихнут, есть какой то прикол в этом
Если интересует мнение сдавшего не этот билет - Количество одно (как ресурс), себестоимость только по партиям (без складов).
-
Посмотрите,пожалуйста, верно ли данное решение оперативного учета
-
По поводу регистра. Изначально была мысль делать Измерение Деталь, Ресурсы: Стеллаж, Количество. Но нашел в ветке об этом регистре такое замечание:
Результат экзамена:
ОУ: неверно организовано хранение информации о составе стеллажа, регистры предназначены для быстрого получения информации по измерениям, а не ресурсам
Коллеги, а что если сделать отдельный справочник "Стеллажи" и подчинить ему справочник "Номенклатуру" с реквизитом "Количество", где хранить комплектующие? Владелец у комплектующего тогда будет только один, чем и будет обеспечена уникальность деталей (приндалежность каждой детали только к одному стеллажу), чтобы не реализовывать контроль уникальности запросом в модуле записей РС при записи?
-
Посмотрите,пожалуйста, верно ли данное решение оперативного учета
При таком типе хранения данных, в запросе вам приходится делать отбор по ресурсу, а не измерению. А это ведь вроде не по феншую, если принимать во внимание инфу из ветки:
|ВЫБРАТЬ
| Комплекты.Номенклатура,
| Комплекты.Комплект КАК Комплект,
| Комплекты.Количество
|ПОМЕСТИТЬ втКомплекты
|ИЗ
| РегистрСведений.Комплекты КАК Комплекты
|ГДЕ
| Комплекты.Комплект В
| (ВЫБРАТЬ
| втТЧ.Номенклатура
| ИЗ
| втТЧ КАК втТЧ)
|
|ИНДЕКСИРОВАТЬ ПО
| Комплект
|;
-
Посмотрите,пожалуйста, верно ли данное решение оперативного учета
При таком типе хранения данных, в запросе вам приходится делать отбор по ресурсу, а не измерению. А это ведь вроде не по феншую, если принимать во внимание инфу из ветки:
|ВЫБРАТЬ
| Комплекты.Номенклатура,
| Комплекты.Комплект КАК Комплект,
| Комплекты.Количество
|ПОМЕСТИТЬ втКомплекты
|ИЗ
| РегистрСведений.Комплекты КАК Комплекты
|ГДЕ
| Комплекты.Комплект В
| (ВЫБРАТЬ
| втТЧ.Номенклатура
| ИЗ
| втТЧ КАК втТЧ)
|
|ИНДЕКСИРОВАТЬ ПО
| Комплект
|;
Спасибо..Какой билет посоветуете здесь который более менее правильный? чтобы посмотреть хоть как решать
-
Посмотрите,пожалуйста, верно ли данное решение оперативного учета
При таком типе хранения данных, в запросе вам приходится делать отбор по ресурсу, а не измерению. А это ведь вроде не по феншую, если принимать во внимание инфу из ветки:
|ВЫБРАТЬ
| Комплекты.Номенклатура,
| Комплекты.Комплект КАК Комплект,
| Комплекты.Количество
|ПОМЕСТИТЬ втКомплекты
|ИЗ
| РегистрСведений.Комплекты КАК Комплекты
|ГДЕ
| Комплекты.Комплект В
| (ВЫБРАТЬ
| втТЧ.Номенклатура
| ИЗ
| втТЧ КАК втТЧ)
|
|ИНДЕКСИРОВАТЬ ПО
| Комплект
|;
Спасибо..Какой билет посоветуете здесь который более менее правильный? чтобы посмотреть хоть как решать
я пока не особо смотрел выложенные здесь, но в основном вроде два подхода: или у как у вас, когда уникальность деталей достигается созданием измерения "Деталь" в РС, но тогда будет отбор по ресурсу и может быть замечание на экзамене (см. выше), либо где-то попадался другой вариант, когда в РС заводят два измерения: "Стеллаж" и "Деталь", а контроль уникальности деталей реализуют в модуле набора записей РС перед записью запросом проверяя - не введена ли эта деталь уже для другого стеллажа.
Но вот интересно, почему подчиненный справочник никто не использует? Я решу сегодня, выложу свой вариант на суд общественности.
-
Сделал ОУ так: Два справочника "Стеллажи" и "Детали". У деталей есть реквизит "стеллаж" и "количество в стеллаже". Соответсвенно, одна деталь может относиться только к одному стеллажу, что требуется в задаче. В тч приходной номенклатура тип - деталь, оприходовать можно только детали. В расходной, соответсвенно, номенклатура составного типа (стеллаж/деталь).
-
Вопрос по расчетной задаче и автомобилям.
В задаче условие: "возможен обмен автомобилями между водителями". Как уже тут обсуждалось, если проецировать на другие задачи, то это такое же условие, как "совместительство в подразделениях допускается".
Исходя из всего этого, для соблюдения этого условия я добавил Автомобиль как измерение регистра расчета. Просматривая решенные задачи на форуме, я вижу, что люди добавляют автомобиль в реквизиты. Почему в реквизиты?
Свое решение прикладываю (БУ + СПР)
-
Как сделать чтобы цена автоматически подставлялась в документе Расходная накладная у стеллажа, есть регистр сведений-цены, для комплектующих подставляет, а для стеллажа не могу додуматься как
Заранее спасибо
-
Вопрос по расчетной задаче и автомобилям.
В задаче условие: "возможен обмен автомобилями между водителями". Как уже тут обсуждалось, если проецировать на другие задачи, то это такое же условие, как "совместительство в подразделениях допускается".
Трактовка не верна. в Данном случае речь не о совместительстве (Невозможно Одновременно работать на 2х автомобилях). Поэтому - реквизит.
-
Как сделать чтобы цена автоматически подставлялась в документе Расходная накладная у стеллажа, есть регистр сведений-цены, для комплектующих подставляет, а для стеллажа не могу додуматься как
Заранее спасибо
Во-первых, Вы обратили внимание, что в текущей версии этого билета задача по УФ заменена задачей по бизнес процессам из билета 14?
Ну если Вы всё-таки хотите прорешать, то не понятно в чем конкретно возникает трудность?
Здесь не нужно как то отдельно обрабатывать комплектующее это или деталь. Выводите пользователю все номенклатуры с ценами и остатками и при выборе пользователем строки переносите в табличную часть номенклатуру с соответствующей ценой.
Проверяется Ваше умение передавать данные между формами и умение работать с динамическим списком.
-
Всем привет)
Выкладываю свое решение 6го билета.
Посмотрите, пожалуйста, покритикуйте.
У меня в билете решение УФ и БП из 14 билета.
-
Добрый день. Выкладываю свое решение 6 билета.
ОУ без рег. сведений для стеллажей.
У кого есть возможность, посмотрите пожалуйста.
-
Расчеты.
Как получить "количество рабочих дней в трех предыдущих месяцах" при расчете средней ставки за отпуск ? По какому графику эти дни должны получаться, по пятидневке или по графику автомобиля, указанному в начислении ?
При расчете рабочих дней не известно на каких автомобилях (т.е. по каким графикам) сотрудник ездил предыдущие три месяца. Ни при начислении надбавки ни при начислении оклада автомобиль (график) не указывается, т.к. эти виды расчета не используют период действия.
Получается что автомобиль указывается только в самом отпуске и кол-во рабочих дней считается или по графику именно этого автомобиля как " "ОсновныеНачисленияДанныеГрафика.ЗначениеБазовыйПериод"." или по пятидневке как "ОсновныеНачисленияДанныеГрафика.ПятидневкаБазовыйПериод".
Я лично склоняюсь к мысли что кол-во рабочих дней надо считать по графику автомобиля, указанного в начислении отпуска, иначе присутствие графиков автомобилей в задаче вообще не имеет смысла.
-
Количество рабочих дней в трёх предыдущих месяцах считается по Базе. "НормаДней (для отпуска)" будет ресурсом, а не реквизитом.
-
Количество рабочих дней в трёх предыдущих месяцах считается по Базе. "НормаДней (для отпуска)" будет ресурсом, а не реквизитом.
И какой же вид начисления будет базовым для отпуска ?
Ps. В отчете еще каким-то боком автомобили нужно прикрутить для сотрудников. Что Белоусов тут хочет от нас, он не говорил ? Добавить автомобиль как реквизит сотрудника ?
-
Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма ВСЕХ начислений за три предыдущих месяца /на кол-во рабочих дней за пред. 3 месяца.
Таким образом в базу будут входить: оклад, надбавка, отпуск.
Слово "Автомобиль" заменяем на подразделение и получаем, что сотрудники могут работать в разных подразделениях, т.е. совместительство допускается, значит "Автомобиль" — это Измерение.
Но это всё просто. Засада в этой задаче вот в этой фразе: "Обратите внимание, в отчете должна отражаться также информация о необходимости перерасчета надбавки при исправлении суммы оплат пассажиров". Стандартно платформа этого контролировать не умеет, поэтому придется контролировать программно.
-
Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма ВСЕХ начислений за три предыдущих месяца /на кол-во рабочих дней за пред. 3 месяца.
Таким образом в базу будут входить: оклад, надбавка, отпуск.
Слово "Автомобиль" заменяем на подразделение и получаем, что сотрудники могут работать в разных подразделениях, т.е. совместительство допускается, значит "Автомобиль" — это Измерение.
Так вот я и спрашиваю, как ты рассчитываешь кол-во рабочих дней за пред. 3 месяца ? Ты говоришь "по базе", ок какой именно вид начисления является базой для отпуска ?
Совместительство - это одновременная работа в двух и более подразделениях, используется когда при вытеснении нужно указать рабочее время какого именно подразделения вытесняем. Т.е. ты считаешь что сотрудник одновременно на 2-20 автомобилях ездит (в один день работает по двум и более графикам) ?
-
А причем тут одновременная работа? Водитель пол-дня работал на одном автомобиле, а вторую половину на другом. Отчет, например, делается за месяц в разрезе автомобилей и сотрудников.
ВАЗ
Иванов
Петров
ГАЗ
Иванов
Сидоров
Про базу я ответил: оклад, надбавка, отпуск. Что тут может быть непонятно? Если непонятен сам механизм расчета по базе, то "курим" матчасть )
-
А причем тут одновременная работа? Водитель пол-дня работал на одном автомобиле, а вторую половину на другом. Отчет, например, делается за месяц в разрезе автомобилей и сотрудников.
ВАЗ
Иванов
Петров
ГАЗ
Иванов
Сидоров
Про базу я ответил: оклад, надбавка, отпуск. Что тут может быть непонятно? Если непонятен сам механизм расчета по базе, то "курим" матчасть )
"Водитель пол-дня работал на одном автомобиле, а вторую половину на другом" - ты полагаешь что это называется "совместительство" ?
Вопрос у меня очень простой, как именно ты посчитаешь базу по ресурсу "рабочие дни" для вида расчета отпуск ?
Оклад и надбавка не периодические виды расчета, для них не применимо понятие "рабочие дни", они вообще не связаны с графиком не так ли ?
-
Не нравиться "совместительство" назови это "совмещением". Один хрен надо делать измерением.
"Оклад не периодический вид расчета" Мдаа … Я же написал: "Кури матчасть". По каким критериям определяется нужен график или нет?
"Начисление зарплаты сотрудникам авто предприятия осуществляется ежемесячно с использованием МЕТОДА ОТКЛОНЕНИЙ". График нужен.
PS. В билетах есть три задачи с табелями. И только в одной из них не нужен график. А двух других для решения необходима Норма времени, поэтому — график и следовательно период действия.
-
Не нравиться "совместительство" назови это "совмещением". Один хрен надо делать измерением.
"Оклад не периодический вид расчета" Мдаа … Я же написал: "Кури матчасть". По каким критериям определяется нужен график или нет?
"Начисление зарплаты сотрудникам авто предприятия осуществляется ежемесячно с использованием МЕТОДА ОТКЛОНЕНИЙ". График нужен.
PS. В билетах есть три задачи с табелями. И только в одной из них не нужен график. А двух других для решения необходима Норма времени, поэтому — график и следовательно период действия.
Т.е. когда ты видишь в условии слово "метод отклонений", то все виды расчета у тебя становятся периодическими и используют график в расчете ?
И условие "Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег" тебя ни на какие мысли не наводит, ты прикручиваешь к нему график, верно ?
Кста, для справки, ты уже на минус 3.5 балла нарешал эту задачу ))
-
Годная статья для "чайников".
"Основные начисления:
Если по виду расчета есть зависимость от графика (имеется в виду регистр сведений с датами календаря), то он относится к основным начислениям.
Пример ОН:
- Оклад
- Что-то, что считается от количества рабочих дней (а для этого нужно использовать график): либо в периоде действия (как оклад), либо в БАЗОВОМ периоде"
https://expert.chistov.pro/public/291885/
-
Годная статья для "чайников".
"Основные начисления:
Если по виду расчета есть зависимость от графика (имеется в виду регистр сведений с датами календаря), то он относится к основным начислениям.
Пример ОН:
- Оклад
- Что-то, что считается от количества рабочих дней (а для этого нужно использовать график): либо в периоде действия (как оклад), либо в БАЗОВОМ периоде"
https://expert.chistov.pro/public/291885/
ага, и какая же зависимость от графика есть у фиксированного вида расчета из этой задачи, не подскажешь ?
напомню его: "Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег".
-
Коллеги, в этой задаче действительно фиксированная сумма не требует периода действия и должна быть связана с соответствующим видом расчета и регистром расчета. Есть совсем свежий отзыв о сниженной на экзамене оценке у сдававшего, сделавшего этот вид расчета с периодом действия.
Рабочие дни для отпуска в этой задаче собираются по пятидневке. Это было уточнено на одной из сдач. Эта задача была у меня на экзамене и данные я собирал именно так.. Нареканий у проверяющих не было.
-
Коллеги, в этой задаче действительно фиксированная сумма не требует периода действия и должна быть связана с соответствующим видом расчета и регистром расчета. Есть совсем свежий отзыв о сниженной на экзамене оценке у сдававшего, сделавшего этот вид расчета с периодом действия.
Рабочие дни для отпуска в этой задаче собираются по пятидневке. Это было уточнено на одной из сдач. Эта задача была у меня на экзамене и данные я собирал именно так.. Нареканий у проверяющих не было.
Чтобы решать без базы. В условии задачи вместо: "Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во рабочих дней за пред. 3 месяца."
Должно быть сказано: "Дни отпуска рассчитываются по пятидневному графику. Средняя дневная ставка определяется как сумма всех начислений за три предыдущих месяца /на кол-во рабочих дней ПО ПЯТИДНЕВКЕ за пред. 3 месяца."
-
Коллеги, в этой задаче действительно фиксированная сумма не требует периода действия и должна быть связана с соответствующим видом расчета и регистром расчета. Есть совсем свежий отзыв о сниженной на экзамене оценке у сдававшего, сделавшего этот вид расчета с периодом действия.
Рабочие дни для отпуска в этой задаче собираются по пятидневке. Это было уточнено на одной из сдач. Эта задача была у меня на экзамене и данные я собирал именно так.. Нареканий у проверяющих не было.
спасибо, "Рабочие дни для отпуска в этой задаче собираются по пятидневке", именно это я и хотел услышать.
-
Сделал ОУ так: Два справочника "Стеллажи" и "Детали". У деталей есть реквизит "стеллаж" и "количество в стеллаже". Соответсвенно, одна деталь может относиться только к одному стеллажу, что требуется в задаче. В тч приходной номенклатура тип - деталь, оприходовать можно только детали. В расходной, соответсвенно, номенклатура составного типа (стеллаж/деталь).
Я полагаю что тут лучше сделать Регистр Сведений для хранения данных о комплектующих стеллажа и в модуле формы проверить уникальность, по крайней мере мы так реализовывали механизм когда по автомобильную конфу пилили.
-
Можно ещё проще. Стеллаж - группа, деталь - элемент. У элемента - реквизит "количество". В отчете — иерархия групп и элементов.
-
Доброго времени суток, уважаемые коллеги! Прошу оценить решение 6го билета. Любым замечанием буду рад прислушаться. Спасибо!
-
Сделал ОУ так: Два справочника "Стеллажи" и "Детали". У деталей есть реквизит "стеллаж" и "количество в стеллаже". Соответсвенно, одна деталь может относиться только к одному стеллажу, что требуется в задаче. В тч приходной номенклатура тип - деталь, оприходовать можно только детали. В расходной, соответсвенно, номенклатура составного типа (стеллаж/деталь).
Я полагаю что тут лучше сделать Регистр Сведений для хранения данных о комплектующих стеллажа и в модуле формы проверить уникальность, по крайней мере мы так реализовывали механизм когда по автомобильную конфу пилили.
Я делал так - Детали и стеллажи - это номенклатура. Добавил перечисление (стеллаж, деталь). В регистре сведений - Стеллаж и деталь измерения (чтобы дублей не было). В итоге мы имеем контроль уникальности, а при соебинении с регистром если нет количества деталей для стеллажа берем количество из документа. А если это стеллаж - количестов деталей в ТЧ умножаем на количество стеллажей. Вот и все :)
-
Если и "стелаж", и "деталь" сделать измерениями, то как раз будут дубли.
Стелаж1, Деталь1
Стелаж2, Деталь1
-
Если и "стелаж", и "деталь" сделать измерениями, то как раз будут дубли.
Стелаж1, Деталь1
Стелаж2, Деталь1
Насколько я помню условие - нужно сделать так, чтобы не дублировались детали в одном стеллаже. Как так получается, что болт для одного стеллажа отличается от болта другого стеллажа?
-
Насколько я помню условие - нужно сделать так, чтобы не дублировались детали в одном стеллаже. Как так получается, что болт для одного стеллажа отличается от болта другого стеллажа?
"Каждый стеллаж представляет собой некоторый фиксированный набор комплектующих (например, 4 стойки, 5 полок и 20 болтов). Необходимо обеспечить уникальность деталей, т.е. ОДНА И ТА ЖЕ деталь не может относиться к РАЗНЫМ стеллажам. "
Да, у каждого стеллажа свои УНИКАЛЬНЫЕ болты!
Совет. Когда решаете задачу, задавайте себе вопрос: "Знание какого механизма платформы должен я продемонстрировать в этой задаче?". А как оно там по жизни — это уже в последнюю очередь.
В данной задаче вы должны продемонстрировать знание того, каким образом обеспечивается уникальность записей в непериодическом регистре сведений.
"Уникальность записей
Важным следствием описанного отличия необъектных сущностей является отсутствие возможности записывать ссылки на эти записи в поля базы данных. Однако, следует заметить, что в модели 1С:Предприятия у каждой сущности есть уникальный ключ. Наличие уникального ключа необходимо системе для решения самых разных задач. Например, это позволяет позиционироваться в табличном поле на некоторую запись. Для всех необъектных сущностей, имеющих регистратор, уникальный ключ включает регистратор и номер строки. Номер строки собственно и используется для обеспечения уникальности записей, а также для упорядочивания записей в пределах регистратора. Для регистров сведений не подчиненных регистратору в качестве уникального ключа выступает совокупность измерений и периода, если регистр периодический."
https://its.1c.ru/db/metod8dev#content:2701:hdoc
-
Насколько я помню условие - нужно сделать так, чтобы не дублировались детали в одном стеллаже. Как так получается, что болт для одного стеллажа отличается от болта другого стеллажа?
"Каждый стеллаж представляет собой некоторый фиксированный набор комплектующих (например, 4 стойки, 5 полок и 20 болтов). Необходимо обеспечить уникальность деталей, т.е. ОДНА И ТА ЖЕ деталь не может относиться к РАЗНЫМ стеллажам. "
Да, у каждого стеллажа свои УНИКАЛЬНЫЕ болты!
Совет. Когда решаете задачу, задавайте себе вопрос: "Знание какого механизма платформы должен я продемонстрировать в этой задаче?". А как оно там по жизни — это уже в последнюю очередь.
В данной задаче вы должны продемонстрировать знание того, каким образом обеспечивается уникальность записей в непериодическом регистре сведений.
"Уникальность записей
Важным следствием описанного отличия необъектных сущностей является отсутствие возможности записывать ссылки на эти записи в поля базы данных. Однако, следует заметить, что в модели 1С:Предприятия у каждой сущности есть уникальный ключ. Наличие уникального ключа необходимо системе для решения самых разных задач. Например, это позволяет позиционироваться в табличном поле на некоторую запись. Для всех необъектных сущностей, имеющих регистратор, уникальный ключ включает регистратор и номер строки. Номер строки собственно и используется для обеспечения уникальности записей, а также для упорядочивания записей в пределах регистратора. Для регистров сведений не подчиненных регистратору в качестве уникального ключа выступает совокупность измерений и периода, если регистр периодический."
https://its.1c.ru/db/metod8dev#content:2701:hdoc
Почему непереодический?
В условиях не сказано что комплект фиксирован и не может меняться, так же как и не сказано что может меняться. Т.е на усмотрение сдающего.
Если мы разрешим менять комплект то нам нужен период, так как мы всегда должны предусматривать перепроведение старых документов.
-
Почему непериодический? Да потому что НЕ периодический!
-
Почему непериодический? Да потому что НЕ периодический!
Это не ответ, я назвал варианты решения, в одном случае нужен именно переодический
-
В этой задаче периодический регистр сведений НЕ нужен. Без вариантов. За создание оного вам снизят оценку.
-
Интересно, реально ли построить отчет как в задаче, только чтобы отображались еще и отсутствующие Товары, теоретически входящие в состав Стеллажа, но по которым нулевые остатки
-
Ребя, есть нормальное условие Задачи этого билета на Периодические Расчеты?
Че курил тот кто составлял условие этой задачи?
Там графики автомобилей вообще не нужны чтоли (только график пятидневки для отпуска)?
Как делать обмен Автомобилями между водителями? На 1 Автомобиле в момент времени может работать только 1 Сотрудник: делать регистр сведений чтоли?
-
Присоединяюсь к вопросу : кто может указать корректный текст условия задачи СПР? Без всяких зачеркиваний, а то получается "тут играем, тут не играем, а тут рыбу заворачивали")))
-
Присоединяюсь к вопросу : кто может указать корректный текст условия задачи СПР? Без всяких зачеркиваний, а то получается "тут играем, тут не играем, а тут рыбу заворачивали")))
Это задача 3.35 из сборника. Не парься по поводу корректного текста. На экзамене ни одна задача (кроме упр. форм) не будет дословно соответствовать текстам из сборника (и из "актуальных билетов") т.к. они там рандомно генерируются. Просто реши задачу 3.35 и все, этого достаточно.
-
БУ: Как думаете, не снимут баллы за получение себестоимости до записи движений, а контроля остатков - после? Траблы из за того, что себестоимость по партиям, а остатки по складам. Видел, тут делали два запроса к регистру бухгалтерии в одном пакетном запросе, но я решил сделать так, потому что читабельнее код.
-
Присоединяюсь к вопросу : кто может указать корректный текст условия задачи СПР? Без всяких зачеркиваний, а то получается "тут играем, тут не играем, а тут рыбу заворачивали")))
Это задача 3.35 из сборника. Не парься по поводу корректного текста. На экзамене ни одна задача (кроме упр. форм) не будет дословно соответствовать текстам из сборника (и из "актуальных билетов") т.к. они там рандомно генерируются. Просто реши задачу 3.35 и все, этого достаточно.
Легко опровергаю твои слова, у меня на экзамене все 3 задачи соответствовали задачам дословно, тем билетам что тут выкладывают.
-
Легко опровергаю твои слова, у меня на экзамене все 3 задачи соответствовали задачам дословно, тем билетам что тут выкладывают.
от какого числа был этот экзамен ?
-
По периодическим расчетам неясно:
1. Не зависимо от отработанного времени сотрудникам предприятия ежемесячно выплачивается фиксированная сумма денег.
2. Один календарный месяц в году сотрудникам предоставляется оплачиваемый отпуск.
В жизни отпуск всегда вытесняет оклад, но в этой задаче получается что ставка капает всегда, даже если он в отпуске.
В таком случае основная ставка и надбавка за пассажиров являются доп.начислениями (без периода действия).
В ОН находится только отпуск?
-
В общем сделал так как написал постом выше.
Не нашел годного решения перерасчета, управляемого из регистра бухгалтерии. Пришлось заморочится и соединять новые записи набора с записями регистратора набора, которые уже есть в ИБ. ТОЛЬКО ТАК условие будет работать 100%. Если кто выложит рабочее решение проще и быстрее - низкий поклон ему.
-
Добрый день! Выкладываю свое решение 6 билета. Критика приветствуется)) По СПР это моя первая решенная задача, поэтому есть сомнения...
ОУ: Комплектация стеллажей реализована через регистр сведений (непереод. и независ.) тут вроде все как у большинства
БУ: без лишних заморочек Себестоимость по партии считается, количество списывается с конкретного склада. Все делаю в одном запросе в Расх.накл. Видела сообщения, что т.о. не корректные остатки на складах зависают, я проблемы не увидела, но могла и проглядеть...
СПР: ОплатаПас., Надбавка, Отпуск - это ОН, ФиксСумма (Оклад) - ДН. Отработанные дни в системе фиксируются Оплатой Пассажиров (проводка вводиться док-ом НачислениеЗарплаты, график привязан к Автомобилям) - этот документ записываю РР.ОН и в РН.ОплатаПассажиров (кол-во дней из этого регистра беру для расчета отпуска). ОплатаПас. - это база для расчета Надбавки. ФиксСумма и Надбавка - база для Отпуска (отрабДни из РН.ОплПас.), при проведении Отпуска в док-те указываю график Пятидневка (ФактДней). автомобиль реквизит в ОН. В отчете Надбавка, Отпуск и ФиксСумма идут без указания конкретного Автомобиля. Ну вот как то так.
-
опять мутное условие!
в отчете у расчетной задачи пустой Автомобиль может быть?
Интересно, что хотят увидеть экзаменаторы, прося построить отчет вида:
Автомобиль | Сотрудник | ВидРасчета=Отпуск | Период | СуммаНачисления
ну какой может быть автомобиль когда сотрудник в отпуске, а по условию "автомобилями можно меняться" (т.е. к сотрудникам они не привязаны, у автомобилей отпусков нет - они всегда в работе)
-
Назови автомобиль "Отпуск" или оставь пустым
-
Я сделал два варианта решения по БУ:
1) без признака суммовой (т.е. стоимость в разрезе складов ведется)
2) с признаком суммовой
На мой взгляд первое решение оптимальнее, т.к. все равно стоимость считывается в разрезе партий, т.е. сумма в разрезе склада закроется в 0 при полном списании. Также делается всего одно левое соединение в запросе документа РасходнаяНакладная и отчета, что производительнее. Отчет также проще делается всего одним запросом, а условным оформлением убираем поле сумма из детальных записей. У меня вопрос, кто-то делал как описано в 1-м варианте на экзамене? Если да, то удалось ли обосновать экзаменаторам правильность данного варианта решения? Или все таки экзаменаторы неявно предполагают, что будет 2-й вариант решения?...
Еще позвольте такой вопрос. Как решаются конфликты условий задач по БУ и ОУ? Например, в билете 6 в ОУ в документе ПриходнаяНакладная склад указывается в шапке, а в задаче по БУ этот склад уже указывается в ТЧ.
-
На все вопросы получил ответы. Протупил, ведь склад указывается в ТЧ, значит признак суммовой необходим.
-
Еще позвольте такой вопрос. Как решаются конфликты условий задач по БУ и ОУ? Например, в билете 6 в ОУ в документе ПриходнаяНакладная склад указывается в шапке, а в задаче по БУ этот склад уже указывается в ТЧ.
Эти билеты в чистом виде не встречаются на экзамене, воспринимайте их не как реальную задачу, а как шаблон для решения.
-
В задаче ПР есть условие
Считать, что после расчета сумма оплат корректировке не подлежит
Поясните пожалуйста, что это значит не совсем понятно, по возможности как реализовать.
Предполагаю, что перед записью документа делать проверку даты документа с текущей датой, в случае если дата <, тогда не давать записывать.
-
Есть информация от сдающих, что задачи ОУ (10 и 6 билеты) должны решаться через ПВХ.
Кто-то уже реализовывал подобные решения на ПВХ? Какие есть мысли?
-
Коллеги Ау тишина наступила .кто еще готовится к платформе
вопрос есть
запись.ДниОтпуска=ВыборкаОтпуск.Факт; //? сколько дней отпуска сказано 1 кал месяц в году 28 дней? как считать по графику пятидневка в условии так сказано.
Отработаные дни за 3 мес из оклада ? предварительно записав их
-
Коллеги Ау тишина наступила .кто еще готовится к платформе
вопрос есть
запись.ДниОтпуска=ВыборкаОтпуск.Факт; //? сколько дней отпуска сказано 1 кал месяц в году 28 дней? как считать по графику пятидневка в условии так сказано.
Отработаные дни за 3 мес из оклада ? предварительно записав их
Привет, все переехали в группу в телеге 21 год на дворе, телега теперь модно.
Запись.ДниОтпуска=ВыборкаОтпуск.Факт сколько дней отпуска сказано 1 кал месяц в году 28 дней? - Тут смотря сколько ты ему поставишь, не от дней отпуск зависит а от базы начислений за предидущие 3 месяца и от отработанных дней по календарю.
Я сделал график пятидневку и по нему посчитал кол-во отработанных дней, но это не гибко. Люди доп параметр вводят для подсчета 5 дневки.