Материалы курса «Подготовка к Аттестации по Платформе 8.2» – Пакет стартовых задач
Первый пакет разобранных задач по Аттестации
Это восемь задач, с которых мы предлагаем Вам начать обучение в курсе.
Почему именно эти задачи и почему именно таким “пакетом”?
Потому что в них прорабатываются все основные приемы и подходы, используемые для решения аттестационных задач – те, что будем использовать дальше, при разборе следующих.
Хотелось бы, что Вы сначала проработали именно этот пакет, от начала до конца, и только затем переходили к следующим задачам – так многое будет более понятным и узнаваемым.
Порядок работы с этим блоком:
- Нужно скачать все задачи модуля
- Обязательно попытаться решить их самостоятельно
- Просмотреть решения задач от начала до конца
- Если после просмотра остаются вопросы – задать их комментариями к этой странице
Общий объем: 10 часов 25 минут видео, в пересчете на учебные часы составляет около 14 учебных часов…
Содержание блока
- Стартовая задача № 1 (оперативный учет)
2 часа 17 минут - Стартовая задача № 2 (оперативный учет)
1 час 03 минуты - Стартовая задача № 3 (бухгалтерский учет)
1 час 12 минут - Стартовая задача № 4 (бухгалтерский учет)
1 час 12 минут - Стартовая задача № 5 (расчетные задачи)
1 час 28 минут - Стартовая задача № 6 (расчетные задачи)
1 час 14 минут - Стартовая задача № 7 (бизнес-процессы)
1 час 05 минут - Стартовая задача № 8 (бизнес-процессы + упр.формы)
55 минут
Описания задач в PDF и видео-решения находятся в архиве Стартовый пакет из 8 задач: DevAtt-Start.rar на стартовой странице.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (1 349):
Комментарии закрыты
Здравствуйте.
Скажите, почему содержание материалов на стартовой странице “Скачать сразу все задачи и их решения>>>Стартовый пакет из 8 задач”и на текущей отличаются? Какой вариант наиболее полный?
Спасибо.
Доброго дня!
Материалы идентичны. Для удобства все архивы с материалами были добавлены на стартовую страницу курса.
Добрый день!
Возник вопрос по 5 задаче: почему платформа потребовала сделать ведущим начисление Оклад по отношению к Компенсации? Ведь если размер Оклада изменится, то это никак не повлияет на количество дней Больничного, от которого зависит Компенсация. Кроме того, Оклад же не может вытеснить Больничный по периоду действия. Или это просто необходимость сохранения иерархии ведомых видов расчета в платформе?
На дни не повлияет, а на базу может повлиять. Но Вы правы, предупреждение возникло именно из-за иерархии зависимостей.
Здравствуйте, Павел!
Вопросы по зависимости от базы на примере 6 задачи.
Разобьем на 2 документа начисления по тарифу за неделю, которая на стыке января и февраля. В документ с датой регистации 01.01 попадают данные с 30 по 31 января, а в документ * с датой регистрации 01.02 данные с 01.02 по 05.02. Если установить в конфигураторе зависимость от базы по периоду регистации, то при перепроведении больничного Каменского (док.№7), в котором базовый период 30.01-05.02 СуммаБаза=312000, а ОтработаноЧасовБаза=312! Причем, если в документе * дату регистрации изменить на 01.01 СуммаБаза и ОтработаноЧасовБаза такое же.
Вопрос №1. Как посмотреть из каких документов собирается база (чтобы знать наверняка)?
Вопрос №2. Догадками и подбором такая база получается если взять данные по Каменскому за весь! январь и первую неделю! февраля 72000+96000+72000+24000+48000=312000. Почему так? Ведь базовый период с 30.01 по 05.02???
1. Посмотреть значение в поле “Регистратор” в базовой таблице.
2. Если база не зависит от периода регистрации, то будет возвращена база по периоду действия.
1) Так ведь в регистраторе документ, для проведения которого собираем базу, а мне нужны документы, из которых база состоит. Помогите, пожалуйста!
2) По периоду действия все получается правильно СуммаБаза=72000. Почему по периоду регистрации криво? Я пробовала и на своей и на вашей базе.
1. Точно. Вам нужно сделать разрез базы по регистратору (правда непонятно зачем). В параметрах виртуальной таблице задайте “Регистратор”, он добавится как еще одно поле.
2. Скорее всего не все базовые записи зарегистрированы в базовом периоде.
Здравствуйте!
Вопросы к задаче №1:
1. Если временная таблица используется далее в соединениях, разве ее не надо индексировать?
2. Строка задания “…Кроме того, в расходной накладной могут также быть указаны услуги (например, доставка)” как раз и означает, что в регистре СебестоимостьТоваров могут отсутствовать записи?
3. Обращается ли внимание на имя табличной части? Например, в расходной накладной вместо ТоварыИУслуги просто Товары ?
Спасибо!
1. Любые поля любых таблиц, если они используются в условии соединения надо индексировать.
2. Мне всегда казалось, что это условие как раз про то, что в ТЧ могут быть услуги. А то что услуг нет в “Себестоимости” это так, но также там может и не быть товаров, если они кончились или никогда не поступали.
3. Нет.
Так значит, при создании временной таблицы ВТ_ДокТЧ так же надо включить “ИНДЕКС ПО Номенклатура” ?
В видео и в базе этого нет.
В курсе нет ни одного полностью решенного задания как в билете, так как предполагает определенный уровень подготовки.
Про индексацию я писал выше.
С точки зрения здравого смысла замечу, что иногда на создание индекса (а это таблица) времени тратиться больше, чем на перебор при соединении. И тут нужно анализировать нужен он или нет. Если это 20 000 строк, то точно нужен, если 2-3 строки, то нет.
Добрый день!
В уроке Стартовая задача № 1. Вы приводите очень очень хорошее правило при проектировании конфигурации “Один показатель – один регистр”. Этому правилу лучше придерживаться именно на экзамене, или при решении реальных задач тоже?
Смутило то что Вы привели пример по в котором объяснили что для того чтобы построить отчет с показателями Остаток, в резерве и свободный остаток нужно создать 2 регистра, но я специально посмотрел в типовой УТ 11.2 сделано не так, там и остаток и резерв хранятся в одном регистре. В УТ 10.3 насколько я помню тоже и резерв и остаток в одном регистре. Большинство регистров имеют несколько показателей, например ТоварыОрганизации, СвободныеОстатки, ТоварыНаСкладах.
Правила придерживаться надо всегда.
В УТ11 насколько я помню есть регистр “Свободные остатки”, который как раз для подобных целей и используется.
Еще вопросик: как так сделали что в модуле подкрашивается синтаксис запроса, и не 1с-кая контекстная подсказка? Это софт “Снегопад” или какой то другой?
Это “Снегопат”.
Здравствуйте!
Вопрос по задаче 4.
Заметил, что решение, приведенное в видеоуроке отличается от решения в демобазе. Какое решение считать более правильным?
В частности,
При проведении документа КорректировкаЗадолженности в видеоуроке проверяется вид счета:
Если Выборка.Отклонение > 0 И Выборка.Вид ВидСчета.Пассивный ИЛИ Выборка.Отклонение 0 И Выборка.Вид = ВидСчета.Пассивный
Тогда
….
В демобазе вид счета не учитывается:
Если Выборка.Отклонение > 0 Тогда
Движение.СчетДт = ПланыСчетов.Хозрасчетный.Покупатели;
Движение.СчетКт = ПланыСчетов.Хозрасчетный.ПрибылиИУбытки;
Движение.ВалютаДт = Выборка.Валюта;
Субконто = Движение.СубконтоДт;
Иначе
Движение.СчетКт = ПланыСчетов.Хозрасчетный.Покупатели;
Движение.СчетДт = ПланыСчетов.Хозрасчетный.ПрибылиИУбытки;
Движение.ВалютаКт = Выборка.Валюта;
Субконто = Движение.СубконтоКт;
КонецЕсли;
Насколько корректно решение данной задачи без учета вида счета?
Опять-таки задача 4, РасходнаяНакладная, модуль формы в демобазе к задаче:
&НаСервереБезКонтекста
Функция ПолучитьВалютуДоговора(Договор)
Возврат Договор.Валюта;
КонецФункции
Хотя в видеоуроке прямо сказано, что “мы так делать не будем, сделаем запросом”.
Насколько критично для экзамена?
Странно. Видео прикладывалось к базе при записи курса и потом не редактировалось.
Вид счета по логике нужен, но по факту не окажет никакого значения на результат. Я бы добавил.
Многие задачи упрощаются в видео и при решении опускаются некоторые момент, которые либо были продемонстрированы ранее, либо предполагается, что Вы имеете необходимый начальный уровень, чтобы Вам их не показывать. Естественно выборка свойства запросом будет лучше, чем обращение через точку.
Тут вопрос не об упрощении, а о разных подходах: в видео одно, говорится “так не делайте”, а в базе сделано именно так. Сбивает с толку.
Как примеры таких вот казусов – “Возврат Договор.Валюта” вместо запроса и оперативное проведение в бухучете.
На аттестации “Возврат Договор.Валюта” не страшно, мы же понимаем, что в спр.Договоры нет табличных частей, и такой неявный запрос не приведет к лишним соединениям.
А то что база от видео отличается это очень странно.
Здравствуйте!
Вопрос по задаче 4.
Для документа КорректировкаЗадолженности в видеоуроке Оперативное проведение = Запретить, в демо-базе к этому уроку Оперативное проведение = Разрешить, кроме того, в модуле при проведении есть обработка этого режима:
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
Движения.Хозрасчетный.Записать();
КонецЕсли;
Вопрос: Почему в видео от этого режима мы отказываемся? И имеет ли вообще смысл оперативное проведение при работе с регистрами бухгалтерии?
Для регистров бухгалтерии, а точнее для большинства сценариев работы бухгалтеров оперативное проведение не используется. Мы не можем применить методику оперативного проведения.
Здравствуйте!
Вопрос по задаче 3.
Если в отчете по продажам делать не соединение таблиц
РегистрБухгалтерии.Управленческий.Обороты(, , , Счет = &СчетТовары, , , КорСчет = &СчетПрибылиУбытки, )
и
РегистрБухгалтерии.Управленческий.Обороты(, , , Счет = &СчетПрибылиУбытки, , , КорСчет = &СчетПокупатели, )
а их объединение с последующей группировкой по номенклатуре и складу – такой способ считается менее оптимальным или равноценным?
Группировка однозначно медленнее.
Здравствуйте!
Вопрос по задаче 3.
Все-таки что было бы оптимальнее, передавать в функцию общего модуля табличную часть документа, протаскивая её через параметры, или в этой функции общего модуля модифицировать текст запроса для выборки табличной части нужного вида документа запросом напрямую?
Запросом, как мне кажется, лучше, особенно если объем таблицы большой. Но это не тема курса, по производительности есть отдельный :)
На экзамене к подобным моментам, которые можно сделать оптимальнее, не придерутся?
Вряд ли это станет причиной снижения баллов.
Здравствуйте!
Вопрос по задаче 3.
Для формирования отчета по продажам в решении на счете “Прибыли и убытки” добавили оборотные субконто “Номенклатура” и “Склад”
При формировании проводок по выручке для счета “Прибыли и убытки” эти субконто заполняются, а при списании себестоимости – нет.
Если фрагмент списания себестоимости переписать так
Проводка = Движения.Управленческий.Добавить();
Проводка.Период = Дата;
Проводка.СчетДт = ПланыСчетов.Управленческий.ПрибылиУбытки;
Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = СтрокаПартий.Номенклатура;
Проводка.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Склад] = Склад;
Проводка.СчетКт = ПланыСчетов.Управленческий.Товары;
Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = СтрокаПартий.Номенклатура;
Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Склад] = Склад;
Проводка.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Партия] = СтрокаПартий.Партия;
Проводка.Сумма = СтрокаПартий.Сумма;
Проводка.КоличествоКт = СтрокаПартий.Количество;
(т.е. при списании себестоимости на счете “Прибыли и убытки” заполнять субконто) – этот вариант с методической точки зрения лучше, равноценен или чем-то хуже, чем предложенный?
Получается, сразу распределяем себестоимость по номенклатуре и складу. Вопрос только – это в решении не сделано намерено или просто не заморачивались?
А зачем нам эта аналитика? В отчете нам надо корр обороты, аналитика там и так есть.
Здравствуйте!
Вопрос по задаче 3.
В модуле документа РасходнаяНакладная в ОбработкеПроведения первые строки:
Движения.Управленческий.Записать();
Движения.Управленческий.Записывать = Истина;
Комментарий за кадром: “важно не забыть очистить движения текущего документа”.
Но в предыдущих задачах (1 и 2) для очистки движений мы использовали команду явной очистки
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.ОстаткиТоваров.Очистить();
Разве это эквивалентные команды? Это действительно работает, или здесь ошибка?
Когда мы явно очищаем движения, это понятно.
Но в задаче 3, когда мы перепроводим документ, разве при простой записи движений они очистятся? Ведь для документа стоит опция “Удаление движений” = “Удалять автоматически при отмене проведения”, т.е., по идее, при перепроведении движения не удаляются автоматом.
Очистить() используется исключительно для универсальности проведения в обычных и упр формах, а также при наличии прочитанных движений.
В этой задаче мы принудительно записываем пустой набор, для того, чтобы при чтении остатков старые движения не попали в расчет виртуальных таблиц.
Вероятно, в задаче 3 надо было тоже предусмотреть анализ на оперативное проведение, а не делать запись пустых движений безусловно?
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.Управленческий.Записать();
КонецЕсли;
А если дату поменяли, и вроде как не оперативный режим, а движения мешаются…
Здравствуйте, Павел!
Кстати по поводу даты: Очистку движений оптимальнее делать, только в том случае если дата в документе увеличилась вверх. Если дата в проведённом документе изменена вниз, тогда движения мешаться НЕ БУДУТ.
В новых типовых решениях от 1С именно так реализован механизм очистки старых движений.
Получается, лишняя запись (для очистки движений), но чтение из оперативных итогов более оптимально, чем расчет итогов на момент за документом? Запись данных ведь, помимо затрат на саму операцию записи в таблицу, потребует также и пересчета итогов.
Пересчета итогов до окончания транзакции не будет.
Здравствуйте!
Вопрос по задаче 2.
В запросе при получении временной таблицы происходит соединение табличной части документа со срезом последних регистра сведений:
…
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.ПродажаТоваров.СписокТоваров КАК ПродажаТоваровСписокТоваров
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.УчетнаяПолитика.СрезПоследних(&МоментВремени, ) КАК УчетнаяПолитикаСрезПоследних
| ПО (ИСТИНА)
Учитывая, что строк в табличной части может быть много, может быть, имеет смысл получить значение учетной политики из среза последний отдельным запросом пакета запросов:
ВЫБРАТЬ
ПродажаТоваровСписокТоваров.Номенклатура КАК Номенклатура,
СУММА(ПродажаТоваровСписокТоваров.Количество) КАК Количество,
СУММА(ПродажаТоваровСписокТоваров.Выручка) КАК Выручка
ПОМЕСТИТЬ ДокТЧ
ИЗ
Документ.ПродажаТоваров.СписокТоваров КАК ПродажаТоваровСписокТоваров
….
;
ВЫБРАТЬ
УчетнаяПолитикаСрезПоследних.МетодСписания
ИЗ
РегистрСведений.УчетнаяПолитика.СрезПоследних(&МоментВремени, ) КАК УчетнаяПолитикаСрезПоследних
Будет ли решение более рациональным, или, наоборот, более затратным? Имеет ли вообще смысл оптимизировать данный момент?
Можно использовать пакетный запрос. Будет лучше чем с соединением. Но это не существенно на экзамене.
Здравствуйте!
Вопрос по задаче 2. В видео (0:28:55) звучит фраза “Если бы контроль отрицательных остатков по каким-либо непонятным причинам мы бы хотели организовывать на основе текущего регистра… [ОстаткиТоваров]”.
Поясните, пожалуйста, что имелось ввиду. В задании, получается, контроль так и реализован. А какой другой вариант – заводить другой регистр для остатков с измерением Номенклатура и ресурсом Количество? Но складской учет не ведется, разреза по складам не требуется.
Все-таки тот вариант контроля отрицательных остатков, который реализован в контексте данной задачи приемлем, или же он приведен лишь в иллюстративных целях и на экзамене за такое решение оценка будет снижена?
В первой задаче была продемонстрирована методика оперативного проведения. Во второй задаче она опущена, я предполагаю, что после первого видео слушатели смогут сами ее применить ко второй задаче.
Тут вопрос о необходимости второго регистра (остатков) для контроля отрицательных остатков – он нужен, или все можно (не снижает оценку на экзамене) делать на одном?
Если необходимо продемонстрировать методику оперативного проведения, то на одном не получится.
Здравствуйте!
Поясните, пожалуйста, в задачах 1 и 2 при создании документов, которые двигают регистры накопления, ставим Удаление движений = “Не удалять автоматически” или “Удалять автоматически при отмене проведения”, но затем при проведении очищаем движения (Движения.Регистр.Очистить()).
А если рассмотреть другой вариант – установить Удаление движений = “Удалять автоматически”, тогда ведь не придется явно очищать движения. Этот вариант чем-то хуже?
Тогда все таблицы движений при перепроведении будут очищаться, что не самый лучший вариант. И это не позволит использовать методику оперативного проведения.
Здравствуйте, Павел!
Читала прошлые обсуждения задач и нашла ваш комментарий по стартовой задаче №2
Striker 18.02.2016
Здравствуйте. Вопрос по стартовой задаче № 2. Какое решение более рациональное: для контроля остатков перед списанием, создать отдельный регистр для учета остатков номенклатуры или же как в примере решения использовать один регистр и для контроля остатков и для себестоимости?
GROOVY 20.02.2016
Два регистра. Один для контроля остатков, второй для расчета себестоимости.
Не очень понимаю, почему в случае задачи №2 правильнее использовать новую методику списания.
Явных причин использовать два регистра по условию задачи нет – складской учет не ведется, партионное списание в целом по организации.
Если добавить 2 регистра накопления – один будет хранить номенклатуру и ресурс количество, а второй номенклатуру, партии и ресурсы количество и стоимость.
В чем же преимущества? Первый регистр хранит избыточную информацию, которая полностью дублируется во втором регистре? При больших оборотах – это неоправданное увеличение размеров БД, плюс дополнительное считывание остатков при каждом проведении. К тому же в реальной жизни списание может пройти не только продажей (брак, недостача еще что-то), т.е. нужен дополнительный контроль, что оба регистра заполнены синхронно.
Все это, насколько я понимаю, чтобы – просто показать умение использовать методику оперативного проведения.
Оправдывает ли цель средства?
Цель средства оправдывает. Мы не блокируем таблицы в том случае если в этом нет необходимости.
Добрый вечер, Павел!
Хочу понять логику выбора того или другого алгоритма списания.
Я представляю себе это так (если что-то неправильно, исправьте, пожалуйста):
Алгоритм – Методика оперативного проведения:
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
Движения.ОстаткиТоваров.Очистить();
Движения.ОстаткиТоваров.Загрузить(ТабЧасть_ДокументаПродажа);
Движения.Записать();
РезультатПоОстаткам = ОстаткиТоваров (получить запросом отрицательные остатки по аналитике из таб части);
Если РезультатПоОстаткам не пустой – отказ транзакции и возврат
Иначе // отрицательных остатков нет
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(“РегистрНакопления.ОстаткиТоваровПоПартиям”);
ЭлементБлокировки.ИсточникДанных = Табличная часть документа продажа;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(“Номенклатура”, “Номенклатура”);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
Запросом получить ОстаткиТоваровПоПартиям
Движения.ОстаткиТоваровПоПартиям.Загрузить(Запрос.Выполнить().Выгрузить());
Движения.ОстаткиТоваровПоПартиям.Записывать = Истина;
Алгоритм – Обычное списание:
Движения.ОстаткиТоваровПоПартиям.Записывать = Истина;
Движения.ОстаткиТоваровПоПартиям.Очистить();
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(“РегистрНакопления.ОстаткиТоваровПоПартиям”);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = Табличная часть документа продажа;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(“Номенклатура”, “Номенклатура”);
Блокировка.Заблокировать();
Запросом получить ОстаткиТоваровПоПартиям (по номенклатуре из таб. части документа продажа)
Обойти результат запроса —> если остатков хватает записать движжения в регистр ОстаткиТоваровПоПартиям
******************************************************************************************************
в первом алгоритме использование свойства Блокировать для изменения приведет к тому, что платформа заблокирует набор записей регистра ОстаткиТоваров от начала записи в регистр до тех пор пока не закончится транзакция проведения (все остальные документы проводящиеся по этой же номенклатуре будут ждать).
Потом с помощью объекта Новый БлокировкаДанных будут заблокированы записи регистра ОстаткиТоваровПоПартиям по номенклатуре из табличной части – они будут одинаково заблокированы как в первом алгоритме так и во втором.
Получается, что единственное преимущество только в случае если при оперативном проведении в результате получились отрицательные остатки и откат транзакции. В противном случае (что по логике вещей должно быть чаще) больше записей в базу – больше блокировок.
Когда по условию задачи без двух регистров не обойтись – выбор очевиден.
А если одного регистра вполне достаточно и для реализации учета и для написания отчетов зачем так делать?
Смысл оперативного проведения сократить время и количество блокировок. Для этих целей создают регистр по которому принимается это самое быстрое решение. Если результат плохой, то решение принимается на основе одной таблицы, которая блокируется минимум времени. Если результат хороший, то тогда уже начинаем списывать партии и все что угодно, и для того чтобы не допустить параллельных изменений одних и тех же данных устанавливаем дополнительные блокировки. Это кстати можно делать уже и не в транзакции проведения документа, а, к примеру, в фоновом задании.
Добрый день!
Появилось два вопроса:
1) Хотел уточнить, при решении билета у нас будет задача по оперативному и бух. учету. Обе задачи в большинстве случаев будут использовать совместно Расходную накладную. Будет ли основанием для снятия баллов реализация проведения в модуле объекта раздельно для Оперативного учета и Бух. учета?
Под раздельным я имею ввиду получение данных в разных запросах(или используя две процедуры для оперативного и бух. учета соответственно) В сборнике задач в конце в примере используется общий запрос для проведения по обоим регистрам(Остатки и Управленческий), хотя закомментирован запрос отдельно для оперативного учета.
В то же время, в сборнике есть пункт: “Состав объектов конфигурации и их структуру необходимо
самостоятельно определить и реализовать для каждого задания. По-
умолчанию, если другое не следует из условия задачи, каждая
микрозадача, характеризующая отдельный вид учета, считается
никак не связанной с другими микрозадачами.”
2) Нужно ли использовать управляемые блокировки при решении задачи по бух. учету и расчетной задачи(зарплата)?
1. Два запроса хуже чем один, если можно обойтись одним. Только исходя из этого могут снять баллы
2. В бух – обязательно. В расчетных нет.
Здравствуйте, Павел!
Вопрос такой: в разделе “про упр. формы” есть задачи, основанные на данных предыдущих заданий. Например задача, где требуется чтобы форма бизнес-процесса обновлялась при выполнении задач, нужно чтобы в конфигурации уже был создан некий бизнес-процесс с задачами и настроенный специальным образом (в сборнике аналогом является задача 5.15)
А в правилах к экзамену сказано, что даётся 3 базовых задачи + дополнительная по бизнес-процессам ИЛИ по управляемым формам.
А тут что получается, нам на экзамене нужно будет и бизнес-процесс создать и форму нарисовать. Сразу две задачи внутри одной выполнить?
Совершенно верно.
Кстати, карта-маршрута (графическая схема) в упр формах до сих пор обновляется только один раз, потом никакую не хочет обновляться, помогает только перекрытие формы
Добрый вечер, Павел!
Вопрос по задаче №1 из стартового пакета:
Это фрагмент запроса из процедуры Обработка проведения документа Продажа товаров (по расчету стоимости списания)
|ВЫБОР
|КОГДА ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) = 0
| ТОГДА 0
|ИНАЧЕ ВЫБОР
| КОГДА ДокТЧ.Количество = ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0)
| ТОГДА СтоимостьТоваровОстатки.СтоимостьОстаток
| ИНАЧЕ ДокТЧ.Количество / СтоимостьТоваровОстатки.КоличествоОстаток * СтоимостьТоваровОстатки.СтоимостьОстаток
| КОНЕЦ
|КОНЕЦ КАК Стоимость
Зачем 2 раза делать проверку на ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) ?
В первое условие попадут все случаи, когда поле СтоимостьТоваровОстатки.КоличествоОстаток = 0 или = NULL.
Все остальные случаи попадут в ИНАЧЕ.
Насколько понимаю, каждая лишняя операция ЕСТЬNULL утяжеляет запрос?
Можете не делать :)
Я уже не помню из-за чего дважды описывал проверку. Логично смотрится, что вторая не нужна.
Павел, здравствуйте!
Есть вопрос по 2 задаче, организация партионного учёта. Там в обработке проведения документа “Продажа товаров” используется запрос:
| вт_ДокТЧ.Номенклатура КАК Номенклатура,
| вт_ДокТЧ.Количество КАК Количество,
| вт_ДокТЧ.Выручка КАК Выручка,
| ОтсаткиТоваровОстатки.Партия КАК Партия,
| ОтсаткиТоваровОстатки.КоличествоОстаток КАК КоличествоОстаток,
| ОтсаткиТоваровОстатки.СтоимостьОстаток КАК СтоимостьОстаток
|ИЗ
| вт_ДокТЧ КАК вт_ДокТЧ
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОтсаткиТоваров.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| вт_ДокТЧ.Номенклатура КАК Номенклатура
| ИЗ
| вт_ДокТЧ КАК вт_ДокТЧ)
|) КАК ОтсаткиТоваровОстатки
| ПО вт_ДокТЧ.Номенклатура = ОтсаткиТоваровОстатки.Номенклатура
|
|УПОРЯДОЧИТЬ ПО
| ОтсаткиТоваровОстатки.Партия.МоментВремени //НаправлениеСортировки
|ИТОГИ
| МАКСИМУМ(Количество),
| МАКСИМУМ(Выручка),
| СУММА(КоличествоОстаток)
|ПО
| Номенклатура
В этом запросе в условии виртуальной таблицы “РегистрНакопления.ОтсаткиТоваров.Остатки” используется выборка из подзапроса как фильтр по номенклатуре. Зачем? Соединение с основной таблицей (вт_ДокТЧ) и так идёт по этому полю, а оптимальность использования подзапроса сомнительна. В регистре накопления “Остатки товаров” номенклатура является первым измерением, индекс по нему платформа точно построит… Или я что-то упускаю?
Спасибо!
При соединении, выборка по остаткам уже будет построена, ПО ВСЕМ ОСТАТКАМ. Но по условию соединения лишние будут отброшены. Мы же в параметрах ВТ позволяем не рассчитывать лишние.
Про индекс не понял. Это тоже вопрос к запросу, или про какой мы индекс? Измерения регистра индексируются, но не результат запроса по измерениям.
Павел, спасибо!
Обоснование фильтра по виртуальной таблице понятно – мы сразу отбрасываем те записи, которые были бы отброшены по условию соединения. Меня просто насторожила оптимальность фильтрации именно таким способом – выборкой из подзапроса. Индекс я имел в виду тот, который будет у регистра накопления – и полагал, что поскольку измерения регистра проиндексированы, то и при соединении в запросе не возникнет проблем с производительностью, когда мы соединяем основную таблицу с неотфильтрованной виртуальной таблицей остатков. То есть, да, мы в правой таблице получим все остатки, но за счёт индекса итоговую выборку получим, как минимум, не медленнее. При более простом запросе и более простом плане запроса.
В общих требованиях от 1с, есть такой пункт “Использование механизма соединения таблиц вместо того, чтобы задать значения параметров виртуальных таблиц”, снижающий бал от 0,5 до 1. Поэтому несмотря на то, что оптимизатор ms sql скорее всего, нормально обработает ситуацию, на экзамене, параметры виртуальных таблиц лучше задавать, чтобы вопросов лишних небыло.
А вот поля КоличествоОстаток и СтоимостьОстаток нужно бы поместить под функцию isnull, это явная ошибка.
Все поля приводить к числу не нужно. Достаточно те, по которым проводятся первичные проверки.
Павел, Дмитрий, спасибо!
Павел, Добрый вечер!
Вопрос по задаче №8. Сохранение картинок. Вы сохранили картинку в справочнике “Номенклатура”, хотя по стандартам 1с, везде сказано, что нужно хранить такие вещи в отдельном месте, по причине производительности.
Правильно ли сделано в данной ситуации?
Существует несколько вариантов работы с картинками/внешними файлами (это не касательно экзамена):
* В базе
* В Другой базе
* В файловом хранилище.
В идеале это вариант №2. Так как ссылки не будут теряться и обращение будет в нотации 1С. Но на экзамене это не нужно, да и реализовать невозможно.
Потому я привел методику из рекомендаций 1С по работе с файлами. Хорошо, когда внешние файлы хранятся в отдельной таблице. Принцип записи одинаковый.
Добрый день, Павел!
Правильно ли понимаю, что в задачах по бизнес-процессам: если из схемы БП видно, что не упоминается информация например о должности, тогда ни в регистр сведений “ПравилаАдресации”, ни где ещё не нужно добавлять столбец “Должность”, а количество строк приведённых в таблице соответствий(Сотрудник-Подразделение-Должность) не нужно всё в регистр сведений переносить как есть, а внести только те записи, которых достаточно, чтобы реализовать адресацию на тех данных, которые приведены в этой таблице?
Абсолютно верно.
Здравствуйте! Вопросы по 3 задачке.
1) Субконто3 (партия) там перемещение и приходная накладная. МоментВремени для сортировки брать у какого документа? У любого?
2) Почему при формировании проводок Дт ПрибылиИУбытки Кт Товары не заполнили субконтоДт
Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = стр.Номенклатура;
Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Склад] = Склад;
3) Нужно ли в обработке проведения расходной и перемещения блокировать регистр бухгалтерии?
4) Не нужно исключить границу у параметра запроса МоментВремени() в модуле проведения?
Здравствуйте.
1. У каждого
2. А у счета Прибыли и убытки есть аналитика по товарам и складам?
3. Нужно
4. Смотря в каком случае, если нужно собственные движения исключить из запроса, то нужно, если нет – то нет.
Павел, Добрый вечер!
Вопрос к разделу расчётных задач: Если встретиться задача, где расчёт з/п будет по недельный. Возможно ли в этом случае получить плановое количество часов/дней, которые должны быть отработаны за определённую неделю? Чисто гипотетически такое возможно стандартно получить на регистрах расчёта? Или план всегда соответствует периодичности регистра расчёта и связанному с ним графику?
План всегда соответствует периодичности регистра расчета.
т.е. в задаче, где з/п начисляется по неделям, тогда плановое количество дней/часов получить НЕВОЗМОЖНО? (имею ввиду штатными средствами – регистров расчёта)
Невозможно. В таблице данных графика ПериодДействия рассчитывается кратными периоду регистра расчета.
Ну и как тогда быть, если попадётся задача, где будет сказано: “Расчёт з/п ведётся по недельно, и необходимо будет реализовать вид расчёта – оклад по дням, где результат считается как ФактДней/ПланДней*БазовыйОклад”???
1. Я не знаю как решать такую задачу стандартными средствами.
2. Я бы сохранил данные графика в регистре накопления оборотов и данные графика получал от-туда с агрегатами это максимально быстро.
3. Можно строить запрос к регистру сведений с отборами, будет немного медленнее чем в п.2.
Здравствуйте, Павел!
Вы в расчётных задачах, для расчёта ресурсов вызываете процедуру из общего модуля и расчёт ресурсов производите именно там.
Лично мне для решения примитивных экзаменационных задач проще описывать всё внутри одной процедуры “ОбработкаПроведения”, т.к. строк не много и при этом всё лежит на одном экране и под рукой.
Не будет ли это причиной понижения бала на экзамене, или есть какие-нибудь требования делать расчёт именно в общих модулях? (если да, то подскажите в каком месте об этом сказано)
Это стандартная методика расчета записей регистров расчета. Позволяет при получении записей сторно не описывать в разных документах одни и тебе алгоритмы. Методика описана в нескольких книгах издававшихся 1С.
То что методика стандартная – понятно.
То что, в 8.1 “ОбработкаПроведения” выполнялась, на клиенте, из-за чего и использовали серверные общие модули – понятно.
То что в типовых используются до сих пор общие модули – тоже понятно.
Но на экзамене, учитывая что документ “Начисление з/п” всегда один, можно такой подход не использовать? (или где-то в общих требованиях сказано, что так нельзя?)
В общих требованиях нигде не сказано. Но также нигде не сказано, что движения в регистры писать надо не в ПРИЗАПИСИ, а в обработке проведения.
Методика вынесения расчета в общий модуль используется для того, чтобы при формировании сторно записей (а какие они будут мы не знаем) не описывать в разных документах одни и тебе алгоритмы расчета этих самых сторно.
Здравствуйте, Павел!
В расчётных задачах: на ряду со “Способом расчёта” не является ли обязательным использовать и “Категорию расчёта” (чтобы зависимые по базе виды расчёта, вводить тем же документом , что из база-образующие)
Или если не сказано в задании, то не стоит на это тратить время?
PS: я лично не нашёл в общих требованиях ни первого, ни второго. Хотя Вы говорили, что “Способ расчёта” является обязательным.
Если сказано, что “записи могут вводиться как доуметом так и разными” (не точная формулировка), то категории/приоритеты обязательны.
Добрый день, Павел!
В расчётных задачах, при выполнении запросов к таблицам регистров расчёта Вы ни где не ставите отбор по свойству Активность, а ведь по логике записи могут быть и не активными и как следствие не должны учитываться.
На экзамене требуется устанавливать отбор по этому полю при чтении из регистров, или можно от него абстрагироваться?
Никогда об этом не задумывался. Не могу дать ответ. По логике, конечно надо исключать такое.
Доброе утро, Павел!
В файле (ATT83PL-2) с сайта 1С, написан перечень механизмов платформы, которые нужно уметь реализовывать.
Среди них есть такие пункты, которые я пока не очень сильно знаю:
24) работа со сводной таблицей;
25) работа с построителем отчета;
Подскажите пожалуйста, какие задачи из сборника нужно решить, чтобы встретилась необходимость применить именно эти механизмы?
При работе с формами в интерфейсе такси эти механизмы не используются. На экзамене задачи с такими механизмами не встречаются.
Механизмы полностью перекрываются по функционалу СКД.
Добрый день, Павел!
Я правильно понимаю, в расчётных задачах, если нигде не сказано, тогда признак сторнирования при расчёте результата, не нужно учитывать?
PS: в общих требованиях я лично такого не увидел, но вдруг пропустил…
Зависит от задачи. Четкого правила нет.
Добрый вечер, Павел!
В блоке расчётных задач, нужно ли где-нибудь учитывать блокировки данных?
Только при автоматизации перерасчетов. Что на экзамене не встречается.
Добрый день, Павел!
В процедурах обработки проведения у документов, Вы для очистки набора записей регистров дополнительно используете метод “Очистить”.
Но ведь в требованиях к экзамену написано “Решение должно одинаково работать как в тонком, так и в Веб-клиенте, если иное не оговорено условием конкретной задачи.”
По умолчанию в управляемой форме для коллекции движений свойство “Использовать всегда” установлено в значение Ложь. Следовательно в тонком клиенте и в веб-клиенте набор записей любых регистров всегда создаётся пустым и не читается по умолчанию. Обычные формы на экзамене не используются и работа системы в них не проверяется.
С учётом вышеизложенного, возникает вопрос: зачем нужно использовать данный метод для очистки наборов записей?
PS: вы ведь везде говорите, не делайте того, чего не сказано в задании
Можете не использовать этот способ.
Мне проще написать 1 строку кода, чем потом отлавливать ситуации когда набор будет прочитан, при открытии формы или перепроведении или отображении движений где либо.
Добрый день, Павел!
Вы сказали, что в общих требованиях сказано, что виды расчёта пользователь должен иметь возможность создавать в ручную и указывать в них способ расчёта. Я проглядел последнюю версию требований ещё раз (файл ATT83PL-2.rtf), и что-то не увидел, такого предложения. Есть ли ещё какие-то требование, которые где-то лежат, но я не в курсе?
Требования к решениям указаны в документе на сайте 1С, в сборнике задач, и в самих билетах.