Тренинг по подготовке к аттестации.
Обсуждение первых 8 задач второго потока
18.06.2012
комментариев 237
Коллеги, на этой странице предлагается задавать вопросы по решениями первых 8 задач второго потока.
Сами задачи были предварительно анонсированы здесь:
https://mg.spec8.ru/2012/06/14/devatt-2n-stream-start-materials/
и здесь:
https://mg.spec8.ru/2012/06/18/devatt-2nd-stream-tasks-5-8/
и опубликованы здесь: https://mg.spec8.ru/devatt-2nd-stream-all-materials/
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись — напишите нам на e-mail поддержки.
8 урок. Время 0:41:35.
Павел, почему вы создали две процедуры (на сервере и на клиенте):
&НаКлиенте
Процедура ОбработатьПодбор(АдресВХ) Экспорт
ЗагрузитьТоварыИзВХ(АдресВХ);
КонецПроцедуры
&НаСервере
Процедура ЗагрузитьТоварыИзВХ(АдресВХ)
Объект.СписокТоваров.Загрузить(ПолучитьИзВременногоХранилища(АдресВХ));
КонецПроцедуры
Ведь можно было просто:
&НаСервере
Процедура ОбработатьПодбор(АдресВХ) Экспорт
Объект.СписокТоваров.Загрузить(ПолучитьИзВременногоХранилища(АдресВХ));
КонецПроцедуры
Ваш вариант оптимизирует производительность? Или почему вы написали именно так?
Я сейчас проверить не могу, но у меня стойкое представление, что вызвать серверную экспортную процедуру из модуля другой формы с клиента я не могу.
У меня работает. Специально проверил и первый вариант (с двумя процедурами) и второй вариант (с 1 процедурой).
Ну нет повода Вам не верить, в воскресенье до баз доеду и все равно проверю :)
И еще вопрос по отчету из 1-го Задания. Скажите, пожалуйста, почему в запросе по регистру остатков мы используем именно необязательное условие {Склад = &Склад}, а не отбор по этому же реквизиту? В чем принципиальная разница?
Опишите Ваш вопрос подробнее.
Склад – это не реквизит, а измерение регистра. Отбор накладывается на результат запроса, а условие в виртуальных таблицах – это предусловие расчета остатков.
Да, Вы правы, вопрос несколько шире. Конструирование отчета для получения одного и того же конечного результата можно произвести различными способами. Например, чтобы ограничить данные одним складом, можно задать необязательное условие в запросе, а можно предусмотреть отбор. Чтобы показать пользователю колонки Количество и Сумма группами НачальныйОстаток, Приход, Расход и КонечныйОстаток, можно организовать соответствующую настройку полей на закладках НаборыДанных и ВычисляемыеПоля, а можно сделать тоже самое в Настройках на закладке Выбранные поля.
Так вот, вопрос: есть ли принципиальная разница, где именно настраивать финальное представление отчета? И если нет, то все же как лучше сделать, чтобы произвести на экзаменатора наилучшее впечатление? :)
Я немного не в тему отвечу :)
Наилучшее впечатление на экзаменатора можно произвести так:
1. Решить экзаменационный билет без грубых ошибок.
2. При очной сдаче:
2.1 Быть красивой девушкой.
2.2 Сдавать в числе первых в том случае если экзаменатор с утра отдохнувший, и в последнюю очередь если экзаменатор с утра с дороги.
2.3 Сдавать его заму когда он обедает.
3. При заочной сдаче:
3.1 Писать сопроводительную записку с комментариями
3.2 Акцентировать внимание на интересных “плюшках” в решении.
Теперь по теме:
Вычисляемые поля рассчитываются на стороне сервера 1С:Предприятия, а наборы данных подготавливаются средствами SQL. На экзамене можно все делать на стороне скуля. На практике, если поля часто игнорируются в отчетах, то стоит их сделать вычисляемыми.
Павел, мне кажется, что в запросе из 1-го Задания вместо кода
<code>
ВЫБОР
КОГДА ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) = 0
ТОГДА 0
ИНАЧЕ ВЫБОР
КОГДА ДокТЧ.Количество = ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0)
ТОГДА СтоимостьТоваровОстатки.СтоимостьОстаток
ИНАЧЕ ДокТЧ.Количество / СтоимостьТоваровОстатки.КоличествоОстаток * СтоимостьТоваровОстатки.СтоимостьОстаток
КОНЕЦ
КОНЕЦ
</code>
можно использовать такой код:
<code>
ВЫБОР
КОГДА ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) = 0
ТОГДА 0
КОГДА ДокТЧ.Количество = СтоимостьТоваровОстатки.КоличествоОстаток
ТОГДА СтоимостьТоваровОстатки.СтоимостьОстаток
ИНАЧЕ ДокТЧ.Количество / СтоимостьТоваровОстатки.КоличествоОстаток * СтоимостьТоваровОстатки.СтоимостьОстаток
КОНЕЦ
</code>
Если я неправа, скажите, пожалуйста, почему.
На мой взгляд особой разницы нет.
Добрый день!
И снова наблюдение по задаче 5.
В условии сказано: “сотрудникам компании начисляется премия процентом от всех начислений, сделанных в предыдущем же расчетном периоде”. То есть если сотруднику в марте была начислена премия, при ее (премии) начислении в апреле сумма мартовской премии должна учитываться при расчете базы для премии, однако при существующих настройках предопределенного элемента Премия плана видов расчета ДопНачисления этого вероятно не произойдет. Поэтому вероятно при настройке данного вида расчета была случайно пропущена галка в ТЧ базовых видов расчета.
Павел, возник еще один вопрос, точнее наблюдение и предложение, по задаче 5 касательно структуры регистра сведений Производственный календарь, а именно измерения Подразделение.
Подобный подход, на мой взгляд, может привести к неоправданному росту числа записей в регистре в случае, если ряд подразделений будут работать по одинаковому графику работы.
Описанная в видеоразборе ситуация, когда для двух подразделений графики работы (по 5 дней в неделю) не совпадают по дням очевидно соответствует ситуации с двумя различными графиками работы, которые в системе должны быть представлены различными элементами справочника “Графики”.
Предложение: Для хранения соответствия графиков работы подразделениям вероятно стоит использовать отдельный периодический регистр сведений с измерением Подразделение и ресурсом График (это если график работы подразделения может изменяться) или же можно записывать график в реквизит справочника “Подразделения” (если изменение графика невозможно).
Если мое наблюдение неверно, поправьте меня, пожалуйста.
Заранее спасибо за прояснение ситуации.
Абстрагируйтесь от “пятидневок”. Предположим есть график “Для пожилых работников”, в администрации сотрудники по этому графику работают 4 дня, в сталелитейном цехе 1 день.
Добрый день.
Вопрос возник при разборе задачи 5.
В условии задачи сказано, что “сотрудники предприятия получают оплату по окладу пропорционально отработанному времени в днях“. Также есть условие, что “в случае болезни сотрудник получает пособие, размер которого определяется как количество часов болезни, умноженное на среднюю часовую ставку“.
Получается, что в регистре сведений, хранящем данные о графиках работы должны храниться 2 ресурса: ЗначениеДень и ЗначениеЧасы. В регистре расчета основные начисления к ресурсам Сумма и ОтработаноДней добавляется ресурс ОтработаноЧасов.
Виды расчета (оклад и больничный по среднему) находятся в одном плане расчетов и записи по ним хранятся в одном регистре расчетов. В регистре расчета мы настраиваем связь с регистром сведений, хранящим данные графиков.
Вопрос 1: в условиях данной задачи в поле “Значение графика” необходимо выбирать ресурс ЗначениеДень?
Вопрос 2: в запросе получения данных для расчета будет иметь место код:
<code>ВЫБРАТЬ …,
ОсновныеНачисленияДанныеГрафика.ЗначениеДеньПериодДействия КАК ДниПлан,
ОсновныеНачисленияДанныеГрафика.ЗначениеДеньФактическийПериодДействия КАК ДниФакт,
ОсновныеНачисленияДанныеГрафика.ЗначениеЧасыПериодДействия КАК ЧасыПлан,
ОсновныеНачисленияДанныеГрафика.ЗначениеЧасыФактическийПериодДействия КАК ЧасыФакт
ИЗ РегистрРасчета.ОсновныеНачисления.ДанныеГрафика(Регистратор = &Регистратор)
…</code>
и в зависимости от способа расчета мы будем ориентироваться на факт/план отработанных дней или факт/план отработанных часов?
1. Да.
2. Оклад по дням, больничный по часам.
Павел, добрый день!
1. По задаче 4 возник вопрос. В отчете ВедомостьПоЗадолженностям (в источнике данных) есть условие:
<code>Где
Регистратор <> Неопределено</code>
Если я правильно понимаю для отбора только оборотов за период без дополнительных записей с остатками на начало и конец периода достаточно в параметрах виртуальной таблицы ОстаткиИОбороты указать “Метод дополнения” как “Движения” ( по умолчанию значение ДвиженияИГраницыПериода) или могут быть побочные действия от установки данного параметра.
2. Вопрос по видеоразбору. В обработке проведения документа Корректировка задолженности при написании универсального кода определения, что имеет место быть прибыль или убытки используется только отклонение и вид счета. Для использования этого кода в условии наличия активно-пассивных счетов необходимо будет добавить условие на остаток и в зависимости от остатка на этом счете определять, какие движения необходимо сделать. Верно?
Приветствую!
1. Перечитал несколько раз. Не понял вопроса, извините.
2. Активно-пассивные счета в задаче отработают корректно. На основе знака отклонения.
2. С активно-пассивными счетами разобралась, спасибо.
1. Попробую переформулировать. В задаче № 4 в отчете
ВедомостьПоЗадолженностям для получения необходимой информации используется код:
<code>ВЫБРАТЬ
ХозрасчетныйОстаткиИОбороты.Субконто1,
ХозрасчетныйОстаткиИОбороты.Субконто2,
ХозрасчетныйОстаткиИОбороты.СуммаНачальныйОстаток,
ХозрасчетныйОстаткиИОбороты.Регистратор,
ХозрасчетныйОстаткиИОбороты.СуммаОборот,
ХозрасчетныйОстаткиИОбороты.СуммаКонечныйОстаток
ИЗ
РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(, , Регистратор, , Счет = &Счет, &МассивСубконто, ) КАК ХозрасчетныйОстаткиИОбороты
Где
Регистратор <> Неопределено </code>
Условие используется для “отсечения” строки результата с остатком на конец периода без движений и соответсвенно документа-регистратора.
В параметрах виртуальной таблицы ОстаткиИОбороты регистра бухгалтерии можно указать «Метод дополнения» как «Движения» ( вместо используемого по умолчанию значения “ДвиженияИГраницыПериода”) и результат получается тот же.
Вопрос: верно ли будет использование данного параметра виртуальной таблицы или же от его установки могут быть побочные действия (возможно не рекомендуется по каким-либо причинам или при отдельных сходных данных может быть потеря части результатов)?
Нам же в отчете нужны накопительные итоги по регистраторам… Я ориентировался именно на это условие отчета.
Здравствуйте. К обучению приступил с запозданием. Надеюсь успею догнать остальных. У меня есть несколько вопросов. Помогите разобраться:
В задаче 2 есть условие: “Считается, что документы задним числом не вводятся, но старые документы могут неоперативно перепроводиться” я реализовал следующим куском кода
<code>
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если (Не Проведен) И РежимПроведения=РежимПроведенияДокумента.Неоперативный
И РежимЗаписи=РежимЗаписиДокумента.Проведение Тогда
Сообщение=Новый СообщениеПользователю;
Сообщение.Текст=”Нельзя проводить новые документы неоперативно”;
Сообщение.УстановитьДанные(Ссылка);
Сообщение.Сообщить();
Отказ=Истина;
КонецЕсли;
КонецПроцедуры
</code>
Правильно я ли сделал? На экзамене будет ошибкой если не реализовать проверку условия неоперативного проведения нового документа? Так как учетная политика задается документом, то пользователь может неоперативно перепровести документ УчетнаяПолитика изменив при этом саму учетную политику. Необходимо ли реализовывать последовательность с входящими документами “Учетная политика” и “Продажа товаров”, или на экзамене не стоит тратить время на это?
По поводу этого условия у 1С. А что будет если пользователь откроет существующий документ, удалит все строки, введет абсолютно другие данные?! Вот и мне не понятно на что нацелено это условие…
Реализовать его Вы можете, ничего плохого в этом нет.
Последовательности хороши в любых задачах. Время на создание последовательности много не уйдет.
Павел.
Есть небольшое наблюдение: если взять перепровести документ ПриходнаяНакладная в форме в задаче № 3, то документ начнёт задваивать, затраивать и т. д. собственно до бесконечности движения.
Проверялось и на конфе поставляемом с курсом (платформа 8.2.15.317).
Вопрос: это косяк платформы?
У меня не задваивает. Платформа та же.
Задваивать может в случае если форма обычная или в форму выведены команды перехода к связанным данным. Это не глюк платформы, а извращенная фишка :)
Да. Павел, вы правы. Действительно на форме есть команда перехода к связанным данным. Спасибо.
I. Shalaev,
Проверьте не стоит ли галочки “Использовать всегда” напротив свойства “Объект.Движения” управляемой формы.
В задаче 5 Вы опустили/упростили условие, что компенсация не больше некоторого значения, для каждого сотрудника, но если не упрощать, то получается, что в документ надо вводить второй реквизит “параметр”, в который сохранять это самое максимальное значение (следуя принципу неизменности пререпроведения)?
Доброго времени суток,
Павел, в первой задаче в отчете “Ведомость по складам ” Вы используете соединение двух наборов данных в самой схеме компоновки данных.
Как я понимаю, в этом случае Левое соединение двух наборов будет выполнено на стороне сервера приложений? В таком случае, не будет ли более эффективным соединять таблицы остатков о оборотов еще в запросе, с тем, чтобы соединение выполнялось на стороне сервера СУБД? Или на экзамене все это не принципиально?
Не принципиально
Павел, добрый день.
Подскажите пожалуйста по трактовке задачи по резервированию. Задача в сборнике (2010 г.) 1.11. Суть задачи в том, что заказ на товар оформляется Заказом покупателя, при этом накладывается резерв на товар, даже если его еще нет на складах. Продажа и снятие резерва происходит док-м Расходная накладная с соответствующим контолем остатков.
Но есть такой абзац “Необходимо предоставить пользователю возможность указать в заказе количество резервируемго товара.” (мое примечание – это и так вроде логично, т.к. оформляется заказ не абстрактный, а конктретный) “При этом следует контролировать количество резерва, чтобы оно не превышало количество заказанного товара“. И речь вроде как все о том же заказе покупателя. С пониманием этой фразы совсем все плохо. Может закралась какая-либо опечатка. Может имеется ввиду, что контролировать, чтобы мы не отгрузили больше, чем заказывал покупатель? но в этом случае придется указывать в РН ЗАказ или покупателя, по которому осуществлять контроль.
Павел, прошу помощи, пока не запуталась окончательно. Спасибо.
Приветствую.
Я тоже часто медитирую над задачами… Не всегда понимание приходит :)
Мое понимание того что привели Вы:
Резервируем товар.
При продаже товара указываем количество резерва за которым приехал покупатель.
При контроле смотрим чтобы продаваемый товар не был зарезервирован еще кем то, в том случае если покупатель забирает товара больше чем он заказывал.
Доброго дня,
Уважаемый Павел,
у меня к Вам вопрос
В решении расчетной задачи Вы приводите отчет о начислениях работникам, в ктором по строкам выводятся группировки по подразделению, работнику, виду расчета, а в колонках – по периоду действия (регистрации). Имеется ли принципиальная возможность построить такой отчет с помощью СКД в транспонированном виде, т.е по строкам – сотрудники и подразделения, а по колонкам – периоды и виды расчетов? Хочу получить что-то вроде расчетной ведомости по периодам.
Второй вопрос:
Нужно ли в состав регистра расчета включать измерение “Подразделение”, если в задаче прямо не говорится, что 1)работник может работать в разных подразделениях, или 2)не требуется получать базу целиком по подразделению (например для начисления премии его руководителю)?
Павел, я извиняюся за назайливость, но хочу, чтобы Вы прокомментировали следующий момент: В расчетных задачах есть таблица с процентами премии и интервалами стажа, которая помещается в регистр сведений. Каким образом можно получить значения ставок премй сразу для всех сотрудников одним запросом в виде: сотрудник (НомерСтроки) – ставка премии. В самом деле, не вносить же ставки премий вручную в документ, сверяясь с бумажной таблицей. Такие примеры есть и в оперативных задачах.
Хотел бы услышать ответы и от слушателей, я думаю, что уровень подготовки их достаточно высок.
Oleg Kashira
1. Конечно. Просто указываете вывод данных в таблицу и в колонки добавляете периоды.
2. Если подразделения нет ни в отчетах, ни в условиях, то зачем его добавлять?
3. Таблицу с процентами премий и другие шкалы можно элементарно подцепять запросами. Я в какой то задаче показывал это точно.
Добрый день, Павел
1. Я хотел бы в колонках отразить не только периоды, но и виды расчета, а у меня не
получается.
3. Вы наверно показывали в задаче для первого потока, а не в нашем потоке.
Вопрос для меня очень актуальный. Я пробывал, но как-то криво получается конструкцией из семи пакетов в запросе. Странно, что этот вопрос никого не интересует, кроме меня. Почему мне никто не подскажет тогда…
Пришлите мне свою базу и таблицу с примером что Вы хотите получить: pavel@spec8.ru и дубль на: pavel@chistov.spb.ru
Уточните, пожалуйста, правило о том, что документ должен помнить все данные, на основе которых формируются движения (в видео речь шла о коэффициентах единиц измерения). Не должен ли документ тогда содержать и реквизит со способом списания? Если не должен, то почему?
Не думаю что это принципиально. Можно сохранить значение.
Идея в том, что данные которые использует документ при проведении делятся на те которые можно спокойно изменить вручную и потом концы с концами не сведешь, а бывают те которые меняются документами, ну к примеру способ списания может устанавливаться документом “Приказ об учетной политике”. В этом случае значение можно не хранить в документе.
Добрый день,
Уважаемый Павел, у меня к вам два вопроса:
1. При решении расчетных задач вы используете поиск в Выборке запроса через структуру, перебирая записи регистра. Однако в решениях, которые Вы бесплатно опубликовали на своем сайте (огромное спасибо Вам за это!), использован обратный метод, т.е перебирая результат запроса, позиционируемся на нужной записи в регистре по ее индексу. На мой скромный взгляд, второй вариант решения более изящный и прозрачный. Как вы думаете, что по этому поводу скажут экзаменаторы?
2. При решении расчетных задач базовые периоды, а также параметры расчетов Вы предлагаете заполнять вручную в документе. Я думаю, что это не совсем правильно. Хотя бы потому, что документ каркасной конфигурации содержит только реквизиты “Дата Начала” и “ДатаОкончания”.
Из условий многих задач требуется автоматически определить значение параметра расчета в зависимости от каких-либо данных, например размер преммии зависит от стажа, выручки и т.п. или Вы предлагаете такие параметры тоже вносить вручную?
Наверно резковато получилось
Приветствую.
1. Второй вариант более универсален, так как не нужно следить за тем что в выборку гарантированно попадут все строки набора.
2. Базовый период можно заполнять как руками, так и автоматом, я думаю это вообще не проблема и вряд ли скажется на оценке. Что касается процента премии зависящего от стажа, то тут конечно нужно строить запрос к регистру сведений, в видео подобный прием продемонстрирован. Так что я не вижу причин по которым Вы не могли бы повторить это :)
Добрый день, Павел.
Вопрос про любую расчетную задачу. Можно не автоматизировать заполнение поля “Параметр” в строках документа “Начисление” ? Это не скажется на оценке, даже если условие задачи намекает на то, что надо бы обеспечить подстановку, например, оклада: “Первоначальное значение оклада может изменяться не чаще, чем один раз в день, но берется на начало расчетного периода” ?
И второе, как правильно трактовать вышеприведенное условие? Оклад может изменяться раз в день, и все эти (в том числе ненужные) оклады должны храниться в регистре? Или периодичность регистра можно сделать равным месяцу, а там пусть в него вводят оклады хоть три раза в день?
Автозаполнение можно не автоматизировать.
Про оклад. надо сделать периодический регистр сведений, с периодом день, но при расчете брать срез последних на начало периода.
Здравствуйте, Павел.
У меня вопрос по задаче 3. Почему Вы не наложили блокировку на счет “Товары” в документе “Перемещение”? Ведь мы обращаемся к регистру бухгалтерии, чтобы считать количественный остаток по счету, а потом делаем проверку на то, чтобы он был больше количества перемещаемого остатка. Если не наложить блокировку мы будем читать “грязные данные”, ведь остаток кто-то другой к моменту проведения нашего документа сможет изменить и мы получим ошибку.
И еще одно замечание: зачем в ОбработкеПроведения Расходной накладной открывать цикл по общим итогам, ведь там всегда будет одна запись – итог?
На мой взгляд, красивее было бы написать:
<code>
ВыборкаОбщийИтог = Результат.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
ВыборкаОбщийИтог.Следующий(); // Общий итог
ВыборкаНоменклатуры = ВыборкаОбщийИтог.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаНоменклатуры.Следующий() Цикл
….
КонецЦикла;
</code>
С уважением, Николай.
Приветствую!
Поддерживаю, блокировка на счет “Товары” при перемещении нужна.
Красота кода дело субъективное :)
Как правильно ввести контроль остатков во 2 задаче? Нужно ли вводить новый РН Остатки,с измерением Номенклатура, Ресурсом Количество и делать все по аналогии с 1-й задачей, или же аттестационная комиссия удовлетворится механизмом контроля из строчки “ВыборкаНоменклатура.Количество > ВыборкаНоменклатура.КоличествоОстаток”?
Нужно продемонстрировать умение использовать оперативное проведение.
Добрый день!
Вопросы по задаче 1, обработке проведения документа “Продажа товаров”,
по списанию стоимости:
– Почему в запросе задействовано левое, а не внутреннее, соединение
таблицы ДокТч и регистра СтоимостьТоваров?
– Зачем в запросе ДокТЧ.Склад (в регистре СтоимостьТоваров склада нет)?
1. Нам же надо продать ВЕСЬ товар из документа, а не только тот который был в остатках.
2. Для формирования движений.
Советую еще раз пересмотреть видео и базу.
Спасибо. В вопросом 1 про левое соединение примерно понятно, – должна быть возможность продать товар, который еще не поступил или почему-то кончился. Так? Причем стоимость товара при такой продаже будет равна нулю (из запроса), ну и что.
Про 2-й вопрос. Пересмотрел еще раз видео и базу, в регистре Стоимость товаров склада не обнаружил. Наверное, запрос (в самом низу модуля, тот, который формирует движения по стоимости) возвращает склад просто так, тем более, что ошибки в этом нет.
1. Если товара нет в остатках, то просто соединение не покажет нам 0. И в итоге мы этот товар просто “проскочим” в контроле и расчете себестоимости.
2. Возможно ошибся, видимо копировал модуль от куда-то.
Павел, смотрю сейчас первый урок. Заметил что у вас работает intellisense + запросы синтаксически подсвечиваются.
Вы используете Снегопат или стоит что-то другое?
Снегопат + шаблоны. Видео про то что я использую будет Вам доступно очено-очень скоро. На странице со всеми материалами.
А использование снегопата не запрещено самой 1С? Просто интересно ) Помнится были споры
Уточните в 1С. Мне никто не запрещает :)
С интересом жду видео. Скачал демку, даже она привнесла приятные нотки в работу ) Не знаю есть ли необходимость в полной версии )
Добрый день, Павел.
В видео-уроке по задаче №1 в модуле проведения документа ПродажаТоваров, есть код:
…
Движения.ОстаткиТоваров.Очистить();
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
Движения.ОстаткиТоваров.Записать();
Иначе
МоментИтогов = МоментВремени();
КонецЕсли;
…
Таким образом, при оперативном проведении документа данные в регистр ОстаткиТоваров не записываются, т.к. перед записью мы их очистили. В поставляемой ИБ с решением задачи так и происходит.
Это ошибка или я не правильно понял логику работы?
Мы очистили движения документа, старые, чтобы они не влияли на получения оперативных итогов.
Добрый день. В 1-ой задаче сказано, что товары и услуги необходимо указывать в одной табличной части. При решении задачи нет разделения номенклатуры по видам и всегда делается движение по регистрам накопления “ОстаткиТоваров” и “СтоимостьТоваров”, выполняется расчёт себестоимости. Будет ли такое решение считаться на экзамене ошибкой?
Будет считаться ошибкой.
Есть проблемы с реализацией этого условия?
Спасибо. Проблем с реализацией нет.
Есть к примеру в билете 2 задачи, с пересекающимися данными по бух и упр. (что-нибудь типа товары/остатки)
Надо ли пытаться сделать один универсальный запрос и один алгоритм(проверка остатков и т.д.), или можно разбить алгоритм проведения на 2 блока(упр. и бух.), со своими запросами и блоками кода)?
Изобретательность и искуство работы с запросами не будет оценено на сертификации. Но я не призываю Вас не делать правильно.
(перечитывая в 5-й раз) ” Но я не призываю Вас не делать правильно.” (с)
Есть ощущение что сказано верно, но суть фразы постоянно ускользает :-) :-) :-)
Дело здесь в том, что данные (например, товары/остатки) по упр. учету могут существенно отличаться от данных бух. учета.
Связано, это хотя бы с тем, что в каркасной конфигурации существует документ “Операция”.
Поэтому не правильно получать данные для бух. учета по тем же регистрам накопления.
Я добавлю… Не только для регистров бухгалтерии можно предусмотреть документ “Операция”. Ну так, гипотетически…
Добрый день. Есть не проблемы, а вопросы. Как лучше сделать, в форме приходного документа не разрешать услуги, или в обработке проведения игнорировать записис услугой? Если второе, то будет ли снижена оценка за получения свойства номенклатуры “Услуга” через точку, или надо это делать запросом? Если запросом, то использование конструктора движений в приходных документах не проходит.
При проведении надо в запросе исключить услуги из контроля остатков и расчета себестоимости.
Павел, извините за назойливость, вопрос был про приходный документ, а ответ – про расходный (про исключение услуги из контроля остатков и расчета себестоимости). В форме приходного документа не нужно запрещать ввод услуги в табличную часть? В обработке проведения приходного документа для исключения услуги из движений допустимо получать признак услуги “через точку” (например, Номенклатура.Услуга) или за это будет снижена оценка, и надо пользоваться запросом?
Простите, проморгал…
Я не думаю что такой контроль вообще нужен. Но если нужен то правильнее реализовать его запросом к ТЧ документа с условием по признаку.
Здравствуйте.
Возник вопрос по задаче №2, точнее по задаче 1.4 из сборника задач для подготовки к экзамену (редакция 3, 2011 г.). Задача отличается от рассмотренной во втором примере наличием трех вместо двух методов списания себестоимости (FIFO, по средней или LIFO).
Можно ли пояснить, как необходимо доработать решение задачи в этом случае.
P.s. В результате поиска возможного решения остановилась на следующем: при смене учетной политики на метод списания “по средней” все существующие остатки со всех партий списываются данным документом, а все списанные товары приходуются этим же документом, но на “нулевую партию”. На нее же записываются товары, поступающие во время действия метода списания “по средней”. При переходе же на другой метод списания (FIFO или LIFO) имеющиеся остатки никак не изменяются, а вновь пришедшие товары сохраняются в разрезе своих партий.
Однако при таком решении при переходе на метод списания “по средней” безвозвратно теряется информация о партиях товаров. Верен ли данный способ решения или нужно, например, каким-либо образом использовать последовательность документов?
Заранее спасибо за ответ.
Исправляю опечатку в предыдущем комментарии: задача в сборнике 1.5
На сертификации именно такое решение и ожидается.
И не дай бог Вам подобный опыт применить в реальной жизни ;)
Не снижается ли оценка на экзамене за поцедуру проведения приходного документа, сделанную конструктором? Ведь такая процедура не учитывает возможное дублирование строк.
На это не обращают внимание.
Добрый день.
Вопрос 1: в оперативных задачах, для того что бы не учитывались собственные движения при перепроведении Вы всегда очищаете набор движений и записываете. В УТ 11 не записывают , а учитывают собственные движения в запросе, выбирая их из физической таблицы движений. Какой подход эффективнее и правильнее?
Вопрос 2: почему всегда перезаписываете движения в регистры, даже те которые не менялись? или такой подход только для быстроты решения задачи.
1. Физически запись произойдет только после окончания транзакции. То что мы очищаем набор записей по сути заставляет систему при чтении данных из регистра самостоятельно учитывать старые движения. Т.е. мы заставляем саму систему делать то вы говорите в УТ сделано.
2. Пример приведите в котором не надо писать движения.
1. Какой же подход эффективнее? очищаем и записываем или учитываем в запросе по движениям.
2. Пример сходу не приведу, но: если перепроводим документ и стоит признак “удалять движения только при отмене”
движения остаются. Можно проанализировать измененные движения и только их добавить/удалить. Хотя этот подход сложнее
в реализации.
2. снимается. это неправильно. это касается проверок – можно проверять только измененные движения.
1. Посчитайте трудозатраты и учтите ограниченное время экзамена.
Здравствуйте, у меня вопрос по второй задаче, для оперативного проведения документа мы записываем пустой набор, чтобы очистить записи. Можно ли вместо этого передавать в качестве параметра Граница, с видом границы не включая, или тогда что-то неверно будет? Что-то я запуталась…
В этом случае система не будет читать основные итоги (они уже рассчитаны), а будет производить временный расчет, что может быть на порядок дольше.
Спасибо
Добрый день. Вопрос по задаче 2.
Следуя правилу “не создавать то что в задаче не требуется (Цена)”, разъясните, что в условии задачи 2 заставляет создавать регистр “Продажи”? Или это методология решений 1С?
А давайте я с Вами подискутирую как с Белоусовым. Это будет дискуссия №3, но я думаю это полезно для всех нас.
Итак,
Без регистра “Продажи” как Вы построите все отчеты?
ЗЫ: Я нацелен на долгий диалог. Абсолютно серьезно.
Без регистра “Продажи”, запрос в отчете “Анализ продаж” можно сформировать с использованием вложенного запроса, в виде объединения 1)выборка из табличных частей проведенных документов ПродажаТоваров за период (номенклатура,0,0, выручка) и 2)выборка из рег.нак.ОстаткиТоваров (Номенклатура, Количество,Себестоимость,0). Поле “Прибыль” расчитывается вместе с группировкой результата.
Ага, можно. “Имитационное получение показателя” – 2 балла.
Вопрос: Любое ли списание товаров является продажей?
Бонус: Не запаримся ли мы группировать данные документа для вывода в отчет? :) И не придется ли нам отчет строить соединяя данные документа с реальной таблицей движений регистра? (а иначе как мы сможет отследить соответствие что оборот = продаже?).
День добрый.
Спасибо, учту.
Ответ: Зависит от рассматриваемой системы. В данной задаче списание товара организовано только при продаже документом ПродажаТоваров. По условию, не всякая продажа является списанием.
Ответ на бонус: Понимаю, что сбор данных таким способом менее эффективен, чем выборка оборотов из регистра. Трудоемкость этого варианта запроса, возможно, сравнима с запросом для движений документа ПродажаТовара. Если в задаче 2, выборка ТЧ из документа Продажа количественно (услуги не в счет) не будет соответствовать расходу по регистру ОстаткиТоваров, значит в системе ошибки (можно добавить поле “разница”).
В таком решении время создания регистра и движений по нему, пошло на создание запроса в отчете Продажи, потому-что основной учетный блок выделен как “учет остатков”.
Если при проведении документа мы формировали временную таблицу ДокТЧ и нам требовалось добавить реквизиты документа, то мы задвали их параметрами, и потом устанавливали параметры запроса из ссылки документа. Например для реквизита “Склад” создавали во ВТ новое поле, объявляли его как &Склад и устанавливали параметр запроса “Склад” равным Ссылка.Склад, а не сразу заводили поле ВТ “Ссылка.Склад”.
Т.е. наш вариант
“Выбрать Номенклатура, &Склад ИЗ Документ.РеализацияТовара.Товары КАК РеализацияТоваровТовары”
Альтернатива:
“Выбрать Номенклатура, Ссылка.Склад ИЗ Документ.РеализацияТовара.Товары КАК РеализацияТоваровТовары”
Это принципиально?
Во втором варианте система построит запрос с левым соединением к таблице документа.
Поясните плз, что Вы имеете ввиду под “построит запрос с левым соединением к таблице документа”. Дайте более развёрнутое пояснение?
И в продолжении темы – а что несёт меньшие “накладные расходы” для системы – выборка
Выбрать
РеализацияТоваровТовары .Номенклатура,
РеализацияТоваровТовары .Ссылка.Склад Как Склад
ИЗ Документ.РеализацияТовара.Товары КАК РеализацияТоваровТовары
где Ссылка = &Ссылка
или
Выбрать
РеализацияТоваровТовары .Номенклатура,
&Склад Как Склад
ИЗ Документ.РеализацияТовара.Товары КАК РеализацияТоваровТовары
где Ссылка = &Ссылка
ВЫБРАТЬ
ДокТЧ.Номенклатура
ИЗ
Документ.Название.ТЧ.
Построит запрос к таблице “Документ.Название.ТЧ”
ВЫБРАТЬ
ДокТЧ.Номенклатура,
ДокТЧ.Ссылка.Дата
ИЗ
Документ.Название.ТЧ.
Построит запрос к таблице “Документ.Название.ТЧ” и к таблице “Документ.Название”
ВЫБРАТЬ
ДокТЧ.Номенклатура,
ДокТЧ.Ссылка.Дата,
ДокТЧ.Номенклатура.Код
ИЗ
Документ.Название.ТЧ.
Построит запрос к таблице “Документ.Название.ТЧ”, “Документ.Название” и “Справочник.Номенклатура”
При этом система будет строить запросы левым соединением. Чем больше точек в запросе, тем больше таблиц используются при построении запроса и больше соединений.
В продолжении темы, надеюсь теперь очевидно что второй вариант более легче.
Еще вопрос по 5 задаче. Когда делается запрос для расчета в общем модуле. Для расчета ДопНачислений (0:45) делается соединение по номеру строки с ФИЗИЧЕСКОЙ ТАБЛИЦЕЙ ДопНачисление виртуальных таблиц ДопНачисление по основной и дополнительной базам. А почему в первом запросе пакета по расчету ОсновныхНачислений не используете физическую таблицу ОсновныеНачисления, а используете связь между собой только виртуальных таблиц ДанныхГрафика и ФПД?
Когда я 2 года назад был на семинаре в 3 учебном центре (и заочно решал задачи), то преподаватель ЗП Больсунов жестко требовал от нас использования в таких запросах физической таблицы, что ОсновныеНачисления, что ДопНачисления. Неиспользование этой таблицы в таком запросе, как я понял, считал грубой ошибкой.
Кто прав?
В таблице “ДанныеГрафика” гарантированно содержатся все строки реальной таблицы. При ее использовании соединяться еще с реальной таблицей неправильно.
В 5 задаче в Общем модуле для расчета зарплаты вы поставили галочку “Вызов сервера”, но не поставили “Привилегированный”. Но ведь она позволяет рассчитывать зарплату расчетчикам с ограниченными правами доступа. Или на сертификации это не существенно?
1. Настройка прав доступа не тема сертификации.
2. У документа “Ввод начислений” установлен флаг “Привилегированный режим при проведении”. Так что нет необходимости в указанном флажке.
/У документа «Ввод начислений» установлен флаг «Привилегированный режим при проведении»./
А этот флаг распространяется на модуль объекта документа или на другие объекты (в частности Общий расчетный модуль), на которые ссылается документ из модуля?
На транзакцию проведения…
Павел, сорри, если вопрос не совсем по теме, на вашем форуме выложен состав актуальных билетов, используемых на сертификации.
Как я понимаю, этот перечень составлен на основе опыта сдающих сертификацию, но доподлинно не известно будут ли именно эти задачи на экзамене? Достаточно ли для подготовки прорешать только эти (предполагаемые) актуальные билеты или все-таки лучше прорешать все задачи из сборника?
:) Я не могу давать гарантий за действия фирмы 1С. Они могут все поменять в любой момент.
ещё вопрос:
зачем в такой конструкции очистка, ведь при выполнении “загрузить()” предыдущие данные очищаются?
<code>
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
Движения.ОстаткиТоваров.Очистить();
Движения.ОстаткиТоваров.Загрузить(РезультатЗапроса.Выгрузить());
Движения.Записать();
</code>
уточню: этот кусок кода записывает движения ещё до получения остатков. например в первой задаче.
Да, в этом случае нет необходимости в очистке.
день добрый.
поскажите какая конструкция предпочтительнее:
<code>
выборка=запрос.выполнить().выбрать;
если выборка.следующий() тогда
значение=выборка.значение;
</code>
или
<code>
значение=запрос.выполнить().выгрузить()[0].значение;
</code>
при условии, что запрос возвращает только одну запись
Первое предпочтительнее. Так как ТЗ (то что “Выгрузить()” возвращает) это тяжелая штука в отличие от выборки.
А разве Выборка “легче” чем ТаблицаЗначений?
Ведь перебор объектной модели всегда тяжелее чем “прямое” обращение в массиву (к конкретной строке табличной части)?
Естественно легче, тип значения “Выборка” специально предназначен для построчного перебора данных, оптимизирован для порционного получения данных из базы. ТЗ будет есть память целиком получая при выгрузке данные из запроса.
Здравствуйте!
Не могу понять что сделал в четвертой задаче не так в документе “Курсовая разница”. Сформировал запрос
<code>
Запрос = Новый Запрос;
Запрос.Текст =
“ВЫБРАТЬ
| УправленческийОстатки.Счет,
| УправленческийОстатки.Субконто1,
| УправленческийОстатки.Субконто2,
| УправленческийОстатки.Валюта,
| УправленческийОстатки.СуммаОстаток,
| УправленческийОстатки.СуммаВалОстаток * ЕСТЬNULL(КурсыВалютСрезПоследних.Курс, 1) – УправленческийОстатки.СуммаОстаток КАК Отклонение,
| УправленческийОстатки.Счет.Вид КАК Вид,
| УправленческийОстатки.Счет.ВидыСубконто.(
| ВидСубконто КАК ВидСубконто,
| НомерСтроки КАК НомерСтроки,
| ТолькоОбороты КАК ТолькоОбороты
| ) КАК ВидыСубконто
|ИЗ
| РегистрБухгалтерии.Управленческий.Остатки(&МоментВремени, Счет.Валютный, , ) КАК УправленческийОстатки
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют.СрезПоследних(&МоментВремени, ) КАК КурсыВалютСрезПоследних
| ПО УправленческийОстатки.Валюта = КурсыВалютСрезПоследних.Валюта
|ГДЕ
| УправленческийОстатки.СуммаВалОстаток * ЕСТЬNULL(КурсыВалютСрезПоследних.Курс, 1) – УправленческийОстатки.СуммаОстаток <> 0”;
</code>
Когда доходит до строк
<code>
Для каждого Стр ИЗ Выборка.ВидыСубконто Цикл
Субконто[Стр.ВидСубконто] = Выборка[“Субконто”+Выборка.НомерСтроки];
КонецЦикла;
</code>
Выходит ошибка “Итератор для значения не определен”. Когда смотрю в режиме отладки чему равен Выборка.ВидыСубконто показывает что равно РезультатЗапроса.
Так и выбирайте как результат запроса.
Выборку сделал из Выборка.ВидыСубконто, все получилось, только не понял почему когда Вы решали сразу получали данные в цикле из Выборка.ВидыСубконто, а мне пришлось дополнительно писать ВыборкаСубконто = Выборка.ВидыСубконто.Выбрать(), и после этого обходить данные выборки.
Добрый день,
не совсем понятен принцип очистки движений документа перед проведением.
В одном месте используется только метод “Очистить()” набора движений, в другом случае только метод “Записать()” (без очистки). И наконец, встречается комбинация методов “Очистить()” и потом “Записать()”. Не могли бы вы прояснить этот момент?
В видео этот вопрос разобран.
Если использовать управляемые формы и при этом не отображать и не читать движения документа, то принудительно очищать движения не нужно. Если в УФ Вы читаете движения (к примеру используете команду “перейти”) то старые движения читаются и без их удаления у нас будет постоянно дублироваться движения при нажатии на кнопку “Провести” не закрывая форму.
если используется обычная форма, то там движения однозначно читаются при открытии формы и там чистить движения нужно обязательно.
Все вышеперечисленное относится к документам со свойством “Очищать при отмене проведения”.
т.е. зависимость от вида формы, а не клиента? бывает ведь и уф в толстом клиенте…
Зависит в первую очередь от того будут прочитаны движения при открытии формы или в какой либо момент существования формы или нет. Проверить работу в разных режимах я думаю Вы можете легко сами.
Во второй задаче метод списания Вы получаете в одном запросе с партиями. Будет ли неошибочным при сдаче получать его отдельным запросом?
На сертификации такие мелочи особой роли не играют, но в реальной эксплуатации системы я рекомендую все что возможно получать как можно меньшим числом запросов.
а конструкцией вида
РегистрыСведений.УчетнаяПолитика.ПолучитьПоследнее(МоментВремени()).МетодСписания
?
Это ничем от запроса в лучшую сторону не отличается. Скорее наоборот – это неуправляемый запрос.
неуправляемый, значит выбирающий, по сути, все реквизиты по регистру?
но ведь там единственный реквизит. Или у “ПолучитьПоследнее” есть еще отрицательные последствия?
По сути запросом то прозрачнее, Вы не только поля конкретные указываете, но и возможности отборов богаче. Что использовать решать Вам. Главное не в цикле это все делать :)
Здравствуйте!
На видео используется очень интересный “синтаксис-помощник”, как его можно “подключить”?
Приветствую. У нас есть видео на эту тему в первом потоке, я попрошу чтобы к нему был доступ и у второго.
присоединяюсь к вопросу. когда можно будет узнать подробности?
Ждем :)
Тоже очень любопытно.
Спасибо!!!!
Здравствуйте!
Посмотрела на данный момент первые две задачи. Вопрос:
В настройках регистра накопления есть Разрешить разделение итогов. Я читала, что если использовать новую методику проведения, то эта галочка должна быть отмечена. В видео про эту настройку ничего не услышала (либо невнимательно смотрела). Если можно, поясните этот момент.
Разделение итогов влияет на скорость параллельного проведения. Приведу пример…
Имеем регистр накопления остатков |Номенклатура|Количество|. При формировании движения “Приход”, движения формируются и обновляется таблица итогов. В момент обновления таблицы итогов она, естественно блокируется. Если одновременно мы покупаем двумя разными документами один и тот же товар то документы при проведении ожидают снятие блокировки с таблицы итогов, то есть выстраиваются в очередь. Но ведь при покупки товаров нет никаких причин параллельно ожидать окончания обновления итогов другого процесса. И именно для такого случая можно разрешить разделение итогов. Тогда первый документ будет обновлять итогов таблице итогов, а второй создаст еще одну запись в таблице с итогами (система будет работать с несколькими строками итогов как с одной, то есть группирование и сворачивание итогов не наша головная боль).
Но вот при продаже товара несмотря на все разделения итогов, мы должны установить блокировку записей до окончания проведения, нам важно не допустить “грязное чтение”, то есть чтение данных которые в этот момент меняются.
Павел, то есть либо использовать объект БлокировкаДанных, либо св-во движений БлокироватьДляИзменения=Истина, верно?
Или всё же если включен режим разделения итогов, то и строку
Движения.<>.БлокироватьДляИзменения=Истина; // что временно снимет галочку разделения итогов, как где-то обсуждалось на Вашем форуме
использовать и
Блокировка = Новый БлокировкаДанных;
Спасибо!!!
Блокировка и разделение итогов не связаны.
В первых видео подробно рассказано когда использовать свойство набора записей “БлокироватьДляИзменения”, а когда объект “БлокировкаДанных”.
“БлокироватьДляИзменения” никаких галочек временно не снимает.
Добрый день,
Помогите плз :-)
Вижу:
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись — напишите нам на e-mail поддержки.
Как я понимаю, потому что из-за имеющегося у меня доступа к материалам первой МГ, регистрацию ко второй мне позволило сделать только с 19.06 и сегодняшний день “выпал” из доступа.
Заранее благодарен, Андрей
Объединил два токена в один :)
Проверяйте…