Материалы курса «Подготовка к Аттестации по Платформе 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):
Комментарии закрыты
Павел, добрый день!
1 Вопрос: В видео к первой задаче, когда Вы вбираете данные документа, Вы говорите, что эффективнее параметр &Склад поместить во временную таблицу, а потом, при наложении фильтров на таблицу остатков использовать такой код: (Номенклатура,Склад) В (Выбрать Вт.Номенклатура,ВТ.Склад ИЗ ВТ), а не Номенклатура В (ВЫБРАТЬ Вт.Номеклатура ИЗ Вт) И Склад = &Склад.
Первый подход априори эффективней второго, или нужно уже по обстоятельствам смотреть, в зависимости от количества разрезов регистров, полей в шапке документа, полей в табличной части документа, сколько в среднем строк набивают туда пользователи и т.д и т.п.? На экзамене, насколько я понимаю, это не принципиально.
И попутно — если я формирую таблицу значений из табличной части документа, для загрузки в набор записей регистра накопления, например, не лучше ли реквизиты шапки документа (Дата, Организация, Подразделение и т.д.) передавать в запрос через параметр, а не обращаться из табличной части к ним в запросе?
2 Вопрос: Как все таки правильно расположить операцию деления при расчете себестоимости? У Вас в первом видео она идет вначале, у Евгения Гилева, в бонусном видео, деление идет в конце, после умножения. Причем он там доводы приводит, почему делить надо в конце, а не в начале. Еще встречал на инфостарте рекомендацию делить в начале, но полученный коэффициент округлять функцией Окр().
Спасибо!
1. Можно написать и (номенклатура, склад) В (Выбрать Вт.Номенклатура, &Склад) результат будет один и тот же. В сравнении приведенных примеров эффективнее будет отбор по множеству, то есть второй вариант.
Попутно: на экзамене не рекомендую делать промежуточную ТЗ для загрузки в движения.
2. Не важно как, главное добавить условие, что при полном списании количества стоимость списывается так-же полностью.
Спасибо! По промежуточной ТЗ — я имел ввиду загрузку движений Приходной накладной сразу в РН:
Или лучше такие движения все равно формировать конструктором движений или обходя запрос по табличной части в цикле?
Можно дать 2 комментария:
1. На экзамене лучше не выпендриваться :) Если запрос простой, то можно и загрузить, а если там эквилибристика специально для загрузки реализована — это будет воспринято отрицательно.
2. Чаще всего на экзамене стараются экономить время, и конструктор движений тут довольно сильно помогает, да и изменить построчное формирование, при необходимости, как правило бывает проще, чем переписывать запрос.
Но решать Вам.
Здравствуйте.
Решаю первые 2 задачи и вот какие вопросы возникли:
— В первой задаче вначале говорится что для каждого показателя нужен свой регистр(остатки и себестоимость были разделены на 2 регистра). Во второй же задаче показатель себестоимость в отдельный регистр не выделялся, а был добавлен в регистр остатков товаров и продублирован в регистр оборотов. Так как все таки поступать нужно? Как определить когда выделять показатель в отдельный регистр, а когда нет?
Где-то в интернете читал, что в этих задачах необходимо регистры создавать по структуре под необходимые отчеты. Но это в задачах для сдачи сертификата,а как в реальных задачах поступать? Ведь там не получится сразу предугадать какие необходимы отчеты, а если создавать кучу регистров не получим ли мы через пол года простенького учета базу данных в 100ГБ и не будут ли тупить документы при проведении по 150 регистрам?=)
— Почему везде где необходимо вывести сообщение используют конструкцию «СообщениеПользователю», не проще ли использовать одной строкой «Сообщить()»?
Всегда действуйте по принципу: 1 показатель = 1 регистр.
В первой задаче 2 показателя: Остаток товаров и Стоимость товаров. У них разные разрезы.
Что Вы храните в регистрах во второй задаче и почему у Вас получилось 2 регистра?
Объект СообщениеПользователю используется для накопления сообщений на стороне сервера и вывода их на клиенте при передаче контекста.
Во второй задаче мы используем регистр накопления(остатков) для остатков товаров и регистр накопления(оборотов) для регистрации продаж. Себестоимость продублирована в оба регистра. Вот непонятно почему ее в данном случае не вынесли в отдельный регистр и не получали соединением?
По СообщениюПользователю разобрался, еще почитал у вас на форуме. Спасибо.
Все правильно, в одном регистре себестоимость — это стоимость товаров в организации, а во втором себестоимость продаж. Не каждое списание товара есть продажа. Это разные показатели.
Добрый День!
просмотрел 1 и 2 задачи
вопрос по структуре регистров. В первой задаче мы используем 2 регистра (я так понял из-за того, что остатки у нас хранились в разрезе складов, а себестоимость списывалась в целом по предприятию). Потом запутался почему мы не можем во 2 задаче использовать 2 регистра 1 для оперативного второй для себестоимости. я сделал 2 регистра не будет ли это избыточностью?
Всегда действуйте по принципу: 1 показатель = 1 регистр.
В первой задаче 2 показателя: Остаток товаров и Стоимость товаров. У них разные разрезы.
Что Вы храните в регистрах во второй задаче и почему у Вас получилось 2 регистра?
Ну я сделал по аналогии как в первой задаче.
1 регистр ОстаткиТоваров измр. Номенклатура рес. Количество
здесь учитываю оперативные остатки.
2 регистр СтоимостьТоваров измр. Номенклатура, Партия ресурс Стоимость,Количество.
в принципе механизм работает вопрос был не будет ли это избыточностью.
Не совсем понятен принцип 1 показатель = 1 регистр
У вас же в решении второй задачи 1 регистр ОстаткиТоваров а в нем 2 показателя Количество и стоимость
Получается что в эту формулу 1 показатель = 1 регистр
нужно еще добавить измерения в разрезе которых хранятся показатели
в 1 задаче у нас остатки хранились в разрезе складов а себестоимость списывалась в целом по организации
поэтому если свести в один регистр количество и стоимость конечно получается не правильно (регистр может не обнулиться будут болтаться минуса как вы и говорили)
поэтому использовали два регистра
Только во втором регистре количество и стоимость общие по организации разрез один номенклатура.
в 2 задаче все значительно упростилось
и остаток по организации и себестоимость по организации просто списывается в разрезе партий и все
получается что в одном регистре храним и остатки и стоимость для списания получается в одном регистре 2 показателя тогда я не пойму эту формулу 1 показатель = 1 регистр если в ней не учитывается в каком разрезе хранится остаток и как списывается себестоимость.
Здесь можно подойти следующим образом.
В первой задаче нам нужно было раздельно хранить информацию о количестве товара (в своих разрезах) и стоимости товара (в других разрезах), два разных показателя. То есть, практически, можно во втором регистре количество не хранить (это немного усложнило бы построение запроса).
Во второй задаче у нас цель — хранение остатков партий товаров в двух единицах измерения, количественный остаток и стоймостной, но показатель один.
Если хотите продемонстрировать умение работать с методикой оперативного проведения — то да нужно 2 регистра.
А так показатель один «Остатки партий товаров».
Спасибо теперь вроде все понятно :-)
Смотрю видео №3 из стартового пакета. там в задании сказано, что при операции «Перемещение» нужно перемещать количество, но субконто «Партия» в дебете счета проставлять ссылку на сам документ «Перемещение». у меня вопрос: если так формировать проводки, то получается что мы в 0 никогда не выйдем по регистру бухгалтерии по субконто Партия? т.к. при поступлении товара партия это документ «Приходная», и при списании тоже «Приходная». а при перемещении другой документ?
При перемещении в кредит пишется документ Приходная, а в Дебет — Перемещение.
Здравствуйте Павел. Я только начал обучение, пока смотрю видео №1 из стартового пакета. У меня вопрос. В регистре «ОстаткиТоваров» у нас 2 измерения «Номенклатура» и «Склад» и количество, а в регистре «СтоимостьТоваров» у нас одно измерение и в ресурсах есть стоимость. Когда мы делаем отчет «ВедомостьПоСкладам», не понятно, зачем мы используем 2 набора данных, если во втором наборе все есть и зачем рассчитываем себестоимость КоличествоНачальныйОстаток / А_КоличествоНачальныйОстаток * СтоимостьНачальныйОстаток
ведь в регистре уже есть эти значения рассчитанные?
спасибо.
Так у нас себестоимость в разрезе склада не хранится.
Что так долго отвечаем ребята? Что это такое? Уже неделя прошла. Можно же как бээ свои обязательства выполнить.
Прошу прощения, был недоступен интернет.
Расчетные задачи. Вопрос по алгоритму с приоритетом расчета.
В книге «Проф разработка» приводится пример расчета записей с приоритетом расчета. Логика решения в общем сводится к следующему:
* Получаем приоритет (как правило реквизит ПланаВидаРасчета) для всех записей в наборе записей документа
* Для каждого приоритета полностью перебираем весь набор и проверяем, если ВидРасчета.Приоритет = текущему приоритету, то эту запись передаем дальше.
* Для этой записи запросом получаем данные, рассчитываем их.
* Перед переходом к след. итерации цикла записываем набор для того, чтобы данные с большим (значением) приоритетом могли обращаться к рассчитанным данным.
Т.е. выходит так, что на КАЖДУЮ строку документа будет запрос.
Я попробовал решить ее след образом.
*При входе в процедуру расчета запросом получаем данные из регистра расчета по регистратору — ссылке этого документа. Подводим итоги по приоритету и способу расчета (так же реквизиту в виде расчета — перечислению), и выгружаем данные в дерево значений.
*В цикле по приоритетам выбираем строки, соответствующего приоритета. Далее в цикле по способу расчета получаем все строки с этим способом. В итоге имеем таблицу значений с определенным приоритетом и способом расчета, которую уже передаем далее для расчета.
При таком подходе, если в документе были виды расчета с одинаковым приоритетом и способом расчета, то они рассчитаются за 1 раз (1 запрос). Если таковых не будет, соотв. в противовес предыдущему варианту получим дополнительную таблицу значений к набору записей документа.
Зато для расчета мы передаем уже готовую таблицу, т.е. нам не нужно каждый раз по-новой перебирать все записи набора.
Какой вариант, на Ваш взгляд, более предпочтительнее? Могу скинуть пример второго решения, если что-то не понятно из описания. Кол-во запросов в цикле при первом решении может быть слишком большим. Второе решение — это попытка как-то оптимизировать это дело (хотя в разы ситуацию не изменит). Может быть есть какое-то более элегантное решение?
Если вопрос, по Вашему мнению, совсем не относится к теме курса, проигнорируйте его.
Спасибо.
Я делю обычно так:
1. Получаю запросом список приоритетов набора записей который рассчитывается.
2. Выгружаю его в массив и перебираю этот массив
3. Для каждого приоритета из массива строю запрос и к набору записей и к базе с условием по приоритету
4. Рассчитываю записи, записываю.
Так, что очень похоже на Ваше решение.
Добрый день, не знал куда написать данный вопрос, он относится к задаче 1.19 из сборника. Задача по учету аналогов. Каким образом их списывать, в курсах вы советуете хранить данные на которые опирается документ при проведении, в самом документе, нужно ли в таком случае хранить список аналогов по номенклатуре в еще одной табличной части документа? И как тогда их учитывать при списании? Как учитывать аналоги при перепроведении документа? Какую методику лучше использовать при контроле остатков?
Не помню наизусть задачу 1.19, но судя по тому что Вы пишите: Нет хранить аналоги с документе не надо. Методика оперативного проведения тут не применима.
Добрый день.
Два глупых вопроса:
По стартовому пакету задач.
Задача №3 (2.17) озвучена Гилевым кажется, его голос, как буд-то из другой серии курсов,но по теме. А задача 4 уже озвучена Чистовым и далее везде.
В четвертой задаче есть момент где Чистов ссылается на предыдущее занятие. И вот вопрос: ничего не пропущено из уроков в этом пакете? Должен ли быть Гилев в этом курсе? Что есть предыдущее занятие?
По аттестации.
Представим аттестацию, получил билет.
Допустим в первой задаче требуется создать ПриходнаяНакладная, РасходнаяНакладная с определенными движениями по регистрам сведений, накоплений.
Во второй задаче билета в задании сказано, что опять же берется ПриходнаяНакладная и делаются новые движения по регистру бухгалтерии при определенной логике, создаются новые реквизиты.
И вот вопрос: На выходе при сдаче экзамена должна получиться конфигурация с документами которые модернизированы согласно всем вопросам билета, со всей полной логикой всех задач билета?
Да, некоторые материалы записывал Евгений.
Записи редактировались в разное время в течении года, так, что возможно, что в оригинале и была ссылка на «прошлое» занятие. В наборе ничего не пропущено :)
Да, в итоге должна получится конфигурация в которой накладная делает движения по всем регистрам по всем задачам.
Добрый день!
Злосчастная задача №2
После прочтения всех комментариев и ваших статей с методикой оперативного учета остатков я разобрался. Вопрос состоит вот в чем:
Можно ли в этой задаче вести оперативный учет по тому же регистру, по которому ведется партионный учет товаров, т.е.:
1) Заполнять регистр движениями без измерения Партии (В регистре сделать измерение партии без проверки на незаполненное )
2) Читать остатки только в разрезе Номенклатуры
3) Решаем проводить или не проводить документ
Является ли это ошибкой и почему?
Нельзя. Так как при формировании движений мы не можем знать ни какие партии должны быть списаны, ни то по какой стоимости они должны быть списаны. Блокировать все партии в регистре по товару — это крайне не эффективно.
Добрый день!
При организации перетаскивания товаров из динамического списка в таблицу в параметре-массиве перетаскиваемых товаров содержатся только ссылки. Получается, чтобы запретить перетаскивание групп, не обойтись без вызова сервера? Хотя признак ЭтоГруппа может присутствовать при этом в динамическом списке.
А есть условие в задаче, что нельзя перетаскивать группы?
Такого условия, конечно, нет. Но подбор групп в накладную не имеет никакого смысла. Спросил, чтобы понять, есть ли возможность перетаскивать еще какие-то данные, кроме ссылки.
Перетаскивание зависит от источника перетаскивания. Самой ссылки достаточно для проверки группа она или нет.
На экзамене не усложняйте.
Добрый день. РежимПроведенияДокумента.Оперативный — системное перечисление? Где посмотреть их?
Что посмотреть? Список системных перечислений? В синтаксис-помощнике в разных ветках.
Здравствуйте!
1. Сколько задач в билете на экзамене? По числу разделов или какие-то могут отсутствовать?
2. Можно ли на экзамене не указывать проверку заполнения в свойствах реквизитов объектов? И на что ещё допускается не тратить время?
С уважением,
Антон
1. Как правило могут отсутствовать 4 или 5 задачи.
2. Все что явно не указано в задаче можно не делать.
Все это в первом видео я, вроде как, проговариваю.
Доброго времени суток.
Вопрос по второй задаче. При заполнении обработки проведения расходной, вы сказали, что в этот раз не будет контроля остатков, т.к. уже показывали его в первой задаче.
Данный ответ следует понимать как:
А) В данном решении можно/нужно контролировать остатки в выборке и там же производить нужные партионные расчеты (соотв. перед запросом ставим блокировку. Старый метод)
Б) В данном решении опущен кусок кода, в котором остатки контролируются новым методом.
В) Ваш вариант, если ни первый, ни второй не верны.
Если вариант Б, тогда вопрос вдогонку. Этот код безусловно записывает данные в разрезе номенклатуры, потом проверяем не получили ли мы минус. Но записывает он их куда? В некий (возможный при этом варианте) дополнительный (третий) регистр, который содержит данные только по кол-ву остатков? Ведь в нашем регистре остатки содержатся в разрезе партий, но списываются из общего кол-ва. Следовательно такую проверку адекватно не провернуть.
Вопрос по блокировкам вообще. Вашу статью я читал (и ни раз), но хотел бы уточнить на 100 процентов.
1. Если есть возможность, то мы стараемся проводить документы по новой методике. В самой просто ситуации имеем одну блокировку, устанавливаемую нами — БлокироватьДляИзменения перед записью наборов.
2. Если таковой возможности нет, то ставим блокировку — Новый БлокировкаДанных.
3. При этом возможна ситуация, когда мы сперва работаем с регистром_1 и первым случаем, а ниже с регистром_2 и случаем вторым (т.е. используем оба вида блокировки).
4. Если мы перепроводим документ оперативно, то движения документа также будут учтены в результате, если мы запрашиваем данные (например остатки) на моментвремени() документа, поскольку когда мы запрашиваем данные из обработки проведения мы имеем дело уже с новым моментом времени для документа, который как мин на 1 сек больше прошлого (до проведения), соотв. это аналогично тому, как если б мы создали границу с включением для моментавремени до проведения.
5. Исходя из пункта 4, если у нас оперативное проведение и контроль остатков до непосредственной манипуляции с ними, то движения надо очистить не только в памяти, но и физически перед запросом.
6. Учитывая пункт 5, перед записью пустых движений необходимо установить блокировку на этот набор, для того, чтобы заблокировать движения, которые были в наборе. Например. В наборе были движения по номенклатуре: 1,2,3,4,5. Мы хотим записать туда движения по номенклатуре 6,7,8,9. Соответственно, когда мы очищаем существующие движение и блокируем пустой набор мы тем самым блокируем записи с номенклатурой 1,2,3,4,5 от чтения, т.е. блокировка пустого набор не приведет к блокировке всей таблицы.
Верны ли утверждения? Спасибо.
1. Б. Нужен третий регистр
2.1, 2.2, 2.3 — Да
2.4 про секунду не верно, Момент времени гораздо мельче секунды. Когда мы проводим документ оперативно, система просто читает данные не на момент времени документа, а берет основные рассчитанные итоги на 3999 год, то есть все движения по регистру, в том числе и старые движения этого документа включаются остатки.
2.5, 2.6 — Да
1. По дополнительному регистру для контроля остатков. Его нужно добавлять всегда (т.е. это и рекомендуемый и, более того, добровольно-принудительный метод, след-но на экзамене ошибка?) или же в ситуации, когда (как во второй задаче) можно выполнить сразу и проверку и нужные манипуляции, можно ограничиться правилом «1 регистр — 1 показатель»?
Проверку можно провести в цикле по итогам, не проводя ненужных вычислений, если где-то не хватит остатков.
Относительно второй задачи выходит, что будет 2 регистра с одинаковым показателем (остатки), но с разными измерениями.
Выходит это лучше, чем 1 регистр и проверка в выборке?
В пример хочу привести задачу по оперативному учету про ячейки (можно назвать ее третьей задачей по оперативному учету).
Напомню, что в этой задаче идет учет количества товара в разрезе стеллажа и ряда. Суммового учета по условию задачи нет.
Поскольку не известно заранее из какой ячейки будем списывать товар, то невозможно провести документ по новой методике с одним регистром. Либо добавляем еще один, либо проводим старым способом, соответственно контролируя возможность проведения (отрицательные остатки) в выборке во внешнем цикле по итогам. В этом случае никаких замечаний от Вас по поводу того, что может быть опущен кусок, не было.
Так что получается в итоге? Выбор количества регистров и способы проведения определяются количеством показателей и здравым смыслом (т.е. не надо во всех случаях добавлять регистр, по которому будем проводить новым способом, потом браться за прочие манипуляции).
В таком случае решение второй задачи не требует третьего регистра и дополнительного кода.
Данные вопрос интересует не только с точки зрения ошибки на экзамене, но и с т.з. практического подхода.
2. По оперативному проведению. Если мы задаем параметр как момент времени, то попросту система игнорирует эту установку и читает итоги (т.е. это поведение не следствие влияния внутренних механизмов, например оперативной отметки, а именно такая инструкция). Т.е. в принципе не важно значение момента в параметре во время проведения (там может стоять что угодно), система все равно прочтет итоги?
Такой механизм применителен только к моменту, т.е. дата или граница (без момента) отработают как и ожидается?
1. Цель оперативной методики проведения снизить время блокировок и их количество.
2. Если в запрос передается точка равная оперативной — то система читает данные из уже рассчитанной таблицы.
Дак как все-таки понимать поведение системы при установке момента времени в оперативном проведении?
Именно как инструкцию самой системы или какую-то скрытую фишку?
В первом случае можно просто установить параметр момент времени, безо всяких проверок режима проведения.
Во втором случае при оперативном проведении желательно передать пустую дату, т.к. если это не прямая инструкция, то так должно быть надежнее.
Под оперативной точкой имеется ввиду оперативная отметка? Она ж появляется при первом проведение документа в рамках сеанса. Соотв. если всех выгнать и перезайти, то будет уже другая отметка. Или в системе хранится самый поздний момент времени проведения документ? Извините, но этот момент не понял.
Поведение системы (документированное) очень логично, при проведении документа в реальном времени система читает оперативные итоги. Установите вы момент времени, или передадите пустую дату — не важно. Как мне кажется — это разбирается на базовом курсе по программированию.
Оперативная отметка зависит от времени сеанса, таймзоны клиента и сервера, и является реальной точкой времени реальной работы. От сеанса не зависит.
Здавствуйте.
В задачах 1 раздела(оперативный учет) и 2 раздела(БУ) говорится о контроле остатков. И о том как это реализовать. Нужно ли, если все делается в одной конфигурации и на одних объектах, дублировать контроль остатков ОУ на БУ. Т.е. делать его и там и там. Может же быть такая ситуация, когда в ОУ по остаткам все будет впорядке а в БУ нет, в итоге будет отказ=истина и документ не проведется. Как будут реагировать экзаменаторы на такие события? Возможно я что-то недопонимаю, просьба прояснить.
Данные для целей БУ нельзя брать из других регистров, ровно как и наоборот. Почитайте список популярных ошибок, там про это есть.
Я задал вопрос о том, зачем делать двойной контроль остатков. И будет ли ошибкой его не сделать в одном из видов учета.
Да, это будет ошибкой. Контроль для целей БУ должен быть произведен на основе регистров бухгалтерии, а для целей ОУ — регистров накопления. Это требование четко сформулировано в списке ошибок, опубликованном на сайте 1С.
Здравствуйте!
В задаче №6, при реализации перерасчета получается, что мы выполняем запрос к таблицам регистров расчета в цикле (в случае если объектов перерасчета несколько). Другой возможный вариант решения: передавать в процедуру расчета массив регистраторов и затем передавать этот массив параметром в запрос. Во втором варианте таблицы в запросе нужно соединять ещё и по регистратору. Какой из вариантов будет более производительным (и предпочтительным на экзамене)? В требованиях к экзамену пишут, что запрос в цикле — это очень не хорошо.
В 8.3 обновление карты маршрута бизнес процесса толком не работает. Похоже, платформа кривая.
С уважением,
Антон
Если массивом передадите, то возможен при изменении базы неправильный расчет. В перерасчетах и оклад и премия будет. А запрос для премии получит базу со старым результатом оклада.
Карта-маршрута в Такси глючит.
1) В третьей задаче (бух. учет) создаем документ «Операция», чтобы «не получить штрафные баллы». В задании ничего про данный документ не сказано. Можно не создавать? Или данный документ должен быть в бухгалтерской подсистеме «по умолчанию».
2) в пятой задаче премия «начисляется процентом от ВСЕХ начислений в предыдущем расчетном периоде». Поэтому для премии базовыми являются все остальные виды расчета, кроме премии. Надо ли делать базовым также и саму премию?
1. Прочитайте общие требования к экзамену. Не думаю, что на создание документа «Операция» у Вас уйдет много времени.
2. Ну если в задача сказано «ВСЕ», то, скорее всего надо. Я бы уточнил у преподавателя.
Добрый день, Павел!
Есть несколько вопросов по первой задаче:
1. В условии задачи по построению отчета сказано: «Создать отчет … о движении материалов с заданной характеристикой «Производитель»». Надо ли это понимать так, что в отчет не должна попадать номенклатура, для которой производитель не указан вообще?
В таком случае есть смысл наложить ограничение на Номенклатуру в виртуальных таблицах остатков: Номенклатура В (ВЫБРАТЬ ).
2. Приводится пример «мягкого условия» — {Склад = &Склад}. В моем случае это условие вот такое (в связи с п.1): Склад = &Склад И Номенклатура В (ВЫБРАТЬ РАЗЛИЧНЫЕ ВТ.Номенклатура ИЗ ВТ КАК ВТ).
Как в моем случае сделать «мягким» только условие по складу?
3. Как я понял по уже имеющимся здесь вопросам, если вместо двух наборов данных и вычисляемых полей в СКД сделать соединение и вычисляемые поля в запросе одного набора, это не будет считаться ошибкой. Однако какой способ лучше и почему? Раз вы приводите 2 набора, то, видимо, этот способ более производителен. Это так?
4. В задании приведен внешний вид отчета. В нем нет колонок вида «Количество Приход», «Сумма приход» и т.п. Только колонки групп — «Приход». Какими настройками можно выключить отображение этих колонок? Не смог этого сделать.
Не усложняйте.
1. Пустой производитель — это тоже производитель.
2. Заключите условие по складу в фигурные скобки.
3. Если соединение делает СКД — то оно выполняется на сервере 1С, а не на сервере СКЛ, что на производительность влияет не лучшим способом. Однако для настроек пользователя, возможно это будет хорошо, так какпри отсутствии полей в настройках из присоединяемого источника, обращение к этому источнику не будет выполнено.
4 Добавьте группу полей, отключите заголовки. Однако на украшательства я не стал бы тратить время.
Здравствуйте!
Не нужно ли в табличной части расходной накладной сохранять себестоимость товара, по которой он списывался при проведении (по аналогии с коэффициентом). Если нет, то почему?
С уважением,
Антон
Себестоимость рассчитываемая величина, при перепроведении может изменится.
Здравствуйте!
В правилах приема экзамена сказано, что запрещается сдавать аттестацию на авторских или типовых конфигурациях.
Значит ли это, что сдавать с пустой базы, как показано в курсе, больше нельзя?
Можно ли из каркасной при начале сдачи удалить все объекты и создать собственные?
Были ли такие прецеденты и каковы были последствия? :)
Если ничего такого сделать нельзя — на какие моменты нужно обратить внимание при начале работы с каркасной конфигурацией?
1. режим управления блокировкой данных
2. разрешить использование обычных форм в управляемом приложении
3. ….
P.S.
Еще возник вопрос по второй задаче из стартового набора.
В отчете по продажам так необходимо вывести кроме данных по прибыли еще и данные по количеству проданного товара.
Что будет более правильным:
— выбирать данные из регистра остатков с видом движения «расход» (но ведь там могут быть и не продажи)?
— выбрать данные по документу продажи (но продавать можем разными документами)?
— добавить в регистр продаж ресурс количество проданного?
Я так думаю, что последний вариант предпочтительней.
С Уважением, Иван.
Сдавать в пустой можно — это неоднократно подтверждали сотрудники фирмы 1С. Есть официальный ответ из УЦ1.
… Добавить в регистр с продажами количество будет единственным правильным решением.
Здравствуйте, Павел
Не будет ли считаться ошибкой на экзамене не использование приоритетов расчета в задаче №5?
Использовать приоритеты надо
Здравствуйте, Павел! В задаче №5 (Сложные периодические расчеты) вы ставите для вида расчета который зависит от базы признак базового вида расчета и этот же самый вид выбираете во вкладке Ведущее, хотя в литературе написано «ведущие виды расчета, — те, от которых он не зависит напрямую, но которые могут оказывать на него влияние через другие виды расчетов». Приведу пример: в задаче №5 для вида расчета Болезнь базой является Оклад, но ведь оклад он напрямую влияет на болезнь зачем тогда мы поставили Оклад ведущим для Болезни? Можно ли вообще обойтись без этой установки? Повлияет ли это как то на оценку?
И еще хотел бы что бы пояснили момент с назначением свойства базовый для измерения «Подразделение» в той же задаче в РР. Насколько я понял это свойство практически аналогично свойству «Ведущий» т.е. будут созданы доп. индексы для быстроты отборов. Но в задаче мы используем соединения между таблицами только по номеру строки, зачем тогда была поставлена эта галочка? Или я что-то не так понимаю?
И еще 1 вопрос по аналогичной теме. Допустим мы поставили у регистра сведений для некоторого измерения свойство «Ведущее», и хотим в запросе связать 2 таблицы по этому измерению, необходимо ли использовать конструкцию «Индексировать ПО» для построения индекса, или же в этом нет необходимости?
Здравствуйте.
1. Ведущие — это те при изменении которых необходимо зависимые по базе пересчитать.
2. При получении базы Вы же связь по подразделению в параметрах ВТ устанавливаете. Вот она и будет существенно быстрее, при индексации измерения регистра расчета.
3. Не понимаю, как эти свойства между собой вообще связаны.
Здравствуйте Павел ! В тексте нескольких задачах по оперативному учету говорится что вместе с продажей товаров могут оказываться услуги . Правильно ли будет в таком случае добавить условие при проверке остатка НОМЕНКЛАТУРЫ исключающее услуги ?
Конечно.
Здравствуйте!
у меня два вопроса:
1) в задаче №5 есть такое требование:
«За каждый день болезни сотрудникам предприятия дополнительно начисляется фиксированная
сумма денег в качестве компенсации затрат на лекарства»
а в Вашем решении вот так:
Сумма = Выборка.ОтработаноДнейБаза * Выборка.Параметр;
т.е. начисление рассчитывается из количества отработанных дней а не дней болезни. Это ошибка или я неправильно понял?
2) вот Ваш код в обработке проведения расходной накладной в первой задаче:
|ВЫБОР
|КОГДА ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) = 0
| ТОГДА 0
| ИНАЧЕ ВЫБОР
| КОГДА ДокТЧ.Количество = ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0)
| ТОГДА СтоимостьТоваровОстатки.СтоимостьОстаток
| ИНАЧЕ ДокТЧ.Количество / СтоимостьТоваровОстатки.КоличествоОстаток * СтоимостьТоваровОстатки.СтоимостьОстаток
| КОНЕЦ
|КОНЕЦ КАК Стоимость
зачем здесь столько проверок на NULL?
думаю можно заменить
ЕСТЬNULL(СтоимостьТоваровОстатки.КоличествоОстаток, 0) = 0
на СтоимостьТоваровОстатки.КоличествоОстаток ЕСТЬ NULL
а во второй ветке вообще убрать, т.к если там NULL то мы в нее не попадем по первому условию. Или за лишние проверки не штрафуют?
1. Выборка.ОтработаноДнейБаза — это количество дней болезни. Это базовые данные для расчета надбавки за лекарства.
2. Думаю Вы можете самостоятельно ввести тестовые данные и оптимизировать, при желании, код. Это не тема курса.
Здравствуйте. Мой вопрос похож на предыдущий. В задаче 2 накладывается управляемая блокировка на результат запроса по табличной части товаров. На просторах интернета есть мнение, что правильно накладывать блокировку следующим образом:
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;
Движения.ОстаткиНоменклатуры.Записать();
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(«РегистрНакопления.ОстаткиНоменклатуры»);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = СписокНоменклатуры
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(«Номенклатура», «Номенклатура»);
Блокировка.Заблокировать();
Это позволит нам заблокировать существующие движения документа в случае если Отказ установится в истину.
В связи с этим у меня 2 вопроса: 1)правилен ли такой подход?
2) нужно ли принудительно считывать движения перед их блокировкой, чтобы быть уверенным, что они наверняка прочитаны. После записи, движения очищаем.
Движения.ОстаткиНоменклатуры.Прочитать();
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;
Движения.ОстаткиНоменклатуры.Записать();
Движения.ОстаткиНоменклатуры.Очистить();
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить(«РегистрНакопления.ОстаткиНоменклатуры»);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = СписокНоменклатуры
ЭлементБлокировки.ИспользоватьИзИсточникаДанных(«Номенклатура», «Номенклатура»);
Блокировка.Заблокировать();
«Это позволит нам заблокировать существующие движения документа в » — с чего Вы взяли, что в табличной части документа старые (существующие) движения?
Мне кажется Вам стоит разобраться с механизмом блокировок более плотно:
http://1c.chistov.pro/2013/07/blog-post_25.html
http://infostart.ru/public/196565/
Здравствуйте. Задача 1.
Представим,что мы препроводим документ ПродажаТоваров, причем
в таблице товаров мы изменили данные.
В модуле объекта мы накладываем блокировку:
Движения.ОстаткиНоменклатуры.Записывать = Истина;
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;
Движения.ОстаткиНоменклатуры.Очистить();
// добавляем новые движения
Движения.Записать();
Далее по коду Отказ может быть установлен в истина.
В этом случае новые движения не запишутся, и документ вернется к прежним движениям (до момента перепроведения). На эти «прежние» движения мы не накладываем блокировку. Они очищаются строкой:
Движения.ОстаткиНоменклатуры.Очистить();
Получается, что другой документ сможет параллельно списать наши товары в минус.
Может быть более правильно будет
наложить блокировку на существующие движения через свойство БлокироватьДляИзменения, а для номенклатуры из табличной части использовать объект БлокировкаДанных.
Здравствуйте. Задача 1.
Представим,что мы препроводим документ ПродажаТоваров, причем
в таблице товаров мы изменили данные.
В модуле объекта мы накладываем блокировку:
Движения.ОстаткиНоменклатуры.Записывать = Истина;
Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;
Движения.ОстаткиНоменклатуры.Очистить();
// добавляем новые движения
Движения.Записать();
Далее по коду Отказ может быть установлен в истина.
В этом случае новые движения не запишутся, и документ вернется к прежним движениям (до момента перепроведения). На эти «прежние» движения мы не накладываем блокировку. Они очищаются строкой:
Движения.ОстаткиНоменклатуры.Очистить();
Получается, что другой документ сможет параллельно бесприпятственно
» На эти “прежние” движения мы не накладываем блокировку.» — накладываем: «Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения = Истина;»
Здравствуйте!
В первой задаче справочник единиц подчинен номенклатуре, то есть для каждой номенклатуры своя единица с одинаковым коэффициентом. Не проще ли создать единицы не подчиненные номенклатуре, просто отражающие коэффициенты пересчета (упаковка 5 шт, упаковка 10 шт и т.д.)? В задании сказано «… для каждой номенклатурной позиции может быть произвольное количество единиц измерения…», это можно понимать и так «… для каждой номенклатурной позиции в документе может быть произвольное количество единиц измерения…», тем более что речь о единицах заходит лишь в контексте продажи товаров, а не учета номенклатуры. Если чем проще, тем лучше, то может быть так лучше?
Коробка для одной номенклатуры не является аналогом коробки для другой.
А разве нужно, чтобы бы они все были разные? Единственным используемым параметром является коэффициент, поэтому для задания упаковка бутылок по 12 штук ничем не отличается от упаковки 12 штук носков. У нас 50тыс. номенклатуры, а упаковок, различающихся коэффициентом, штук 20.
Будет ли считаться ошибкой на экзамене использование независимого справочника единиц?
Не думаю, что это критично на экзамене.
Павел, здравствуйте! Задачи расчета: если мы вводим дополнительные начисления в том же документе, что и основные, то база не считается. Что нужно сделать, чтобы можно было считать основные и доп. начисления в одном документе? Будет ли считаться недочетом, если доп. начисления считаются только в отдельном документе?
P.s. Базовый период дополнительных начислений совпадает с периодом действия основных начислений для одного документа
Приветствую.
Базовые начисления должны рассчитаться и записаться в регистр до получения их как базы. Либо разными документами, либо в цикле по «приоритетам».
Здравствуйте, Павел.
У меня методологический вопрос по задаче №2. Там мы данные по текущей учетной политике (FIFO, LIFO) получаем каждый раз при перепроведении документа из регистра сведений, и не сохраняем эти данные в реквизите документа. Получается, что если пользователь изменит документ Установки учетной политики задним числом, то это повлияет на схему проведения документа Расходная накладная. А как же концепция: «Все данные, влияющие на проведение документа должны храниться в самом документе»? Не является ли ошибкой на экзамене приведенное в решении упрощение?
На экзамене — нет. В жизни — либо последовательности, либо все в документах храним.
Павел добрый день.
Во 2 задании в обработке проведения «ПродажаТоваров» вы делаете проверку на заполненность метода списания. Напомню код.
«ВЫБРАТЬ
| ПродажаТоваровСписокТоваров.Номенклатура КАК Номенклатура,
| СУММА(ПродажаТоваровСписокТоваров.Количество) КАК Количество,
| СУММА(ПродажаТоваровСписокТоваров.Выручка) КАК Выручка,
| УчетнаяПолитикаСрезПоследних.МетодСписания
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.ПродажаТоваров.СписокТоваров КАК ПродажаТоваровСписокТоваров
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.УчетнаяПолитика.СрезПоследних(&МоментВремени, ) КАК УчетнаяПолитикаСрезПоследних
| ПО (ИСТИНА)
|ГДЕ
| ПродажаТоваровСписокТоваров.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| ПродажаТоваровСписокТоваров.Номенклатура,
| УчетнаяПолитикаСрезПоследних.МетодСписания
|
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДокТЧ.Номенклатура,
| ДокТЧ.МетодСписания
|ИЗ
| ДокТЧ КАК ДокТЧ»;
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.ОстаткиТоваров.Записать();
КонецЕсли;
Запрос.УстановитьПараметр(«МоментВремени», МоментВремени());
Запрос.УстановитьПараметр(«Ссылка», Ссылка);
РезультатПоТЧ = Запрос.Выполнить();
Если РезультатПоТЧ.Пустой() Тогда
Возврат;
КонецЕсли;
Данные = РезультатПоТЧ.Выбрать(); Данные.Следующий();
УчетнаяПолитика = Данные.МетодСписания;
Но если учетная политика не заполнена , то проверка РезультатПоТЧ.Пустой() не выявит данной ошибки так как методсписания присоединяем по истине к ТЧ документа.
Как лучше сделать получить результат запроса и потом проверять заполнено ли поле Данные.МетодСписания или получить срезпоследних отдельным запросом?
Будет метод списания пустой. Я в курсе редко все все все «защиты от дурака» делаю. Думаю Вы можете самостоятельно проверки на заполненность/незаполненность сделать.
Здравствуйте, Павел
В задаче 5.2 (сборник ред.3) есть такое предложение
«Сама фотография должна храниться либо в иб, либо в виде отдельного файла, в зависимости от желания пользователя».
Вы показали в решении стартовой задачи 8 как это сделать в ИБ, а для того чтобы хранить фотографию в виде отдельного файла надо добавить реквизит типа Строка, который будет хранить путь к этой картинке и при создании на сервере загружать ее. Правильно ли я понимаю или нет? Спасибо.
Да
Добрый день Павел.
Во 2 задаче вы говорите что будут разобраны 4 сценария . (Учет партий, Резервирование, Стеллажи комплектации , Бюджетирование). Учет партий рассматривается во 2 задачи и 3 последующих будут рассмотрены в следующих 3 занятиях, а следующее занятие уже по бухгалтерскому учету.Где будут рассматриваться остальные 3 сценария?
В следующих видео. Я не вспомню что в каком. Смотрите по тексту заданий.
Павел, Здравствуйте!
Старт Пак Задача 3 Вопросы:
1. Мы остерегаемся дублировать код. За это снимают балы на экзамене или это просто правило хорошего тона?
2. Когда следует использовать в запросе индексирование по полю? В СтПак1 мы не использовали индекс Номенклатура для ВТДокТЧ? А в СтПак 3 – используем?
3. Порядок Субконто на счете (у нас Номенклатура, Склад, Партия) какую играет роль? Здесь тоже есть попадание в индекс? При выборе порядка субконто такие же правила что и при выборе порядка следования измерений в Рег Накопления?
4. Формула СуммаПартии = КоличествоПартии * ВыборкаПартии.СуммаОстаток/ВыборкаПартии.КоличествоОстаток; Правильна?
Либо следует использовать ОКР(КоличествоПартии / ВыборкаПартии.КоличествоОстаток * ВыборкаПартии.СуммаОстаток, 2); ?
5. Мы делаем проверку деления на 0 при расчете себестоимости списания. Если у нас выскакивает 0 по остатку — то мы его пропускаем (почему не делаем отказ от проведения документа?).
Так следует поступать всегда когда делитель м.б. 0? Не понятно откуда возможно появиться 0. Если можно, приведите пример.
Спасибо за ответы.
1. Баллы не снимают.
2. Для экзамена роли не играет. В реальности целесообразность напрямую зависит от количества индексируемых значений.
3. Да, так же как РН.
4. В чем разница? Проблемы «последний копейки» ОКР не исправит.
5. Отказ делаем, просто из цикла не выходим, все данные то запросом уже получили, грех не перебрать все и не проверить чего еще не хватило.
Павел, Вам можно задавать вопросы про решение задач 1С Специалист по платформе, которые мы не разбираем в этом курсе?
Рассмотренные задачи покрывают 99% сценариев которые решаются на экзамене. Предлагаю этим и ограничится. Перерешивать все ~300 задач я не буду :)
Задача 6 ЗП.
1. Перерасчеты. В процедуре расчета ресурсов при обращении к данным базы и графика Вы их ограничиваете разрезами перерасчета (сотрудником и видом расчета), а движения самого документа — нет. Таким образом, для некоторых записей движения база=0 и часыфакт=0 и ресурсы регистра рассчитаются неправильно. Это упущение?
2. Перерасчеты. Даже если мы перерассчитываем выборочные записи движения, например только одну строку из 100, тем не менее при перепроведении такого документа в таблице перерасчетов зарегистрируются все зависимые документы таким образом, как будто изменились все 100 строк. Правильно? При таком подходе для меня полезность перерасчетов выглядит весьма сомнительно, ведь перепроведение одного документа на практике потащит по цепочке все более поздние документы (в том числе проведя документ на основании таблицы перерасчетов — можем получить необхимость проведения других документов). Поправьте меня если я не прав, пожалуйста.
3. Бизнес-процессы. Можете рассказать что за кнопка «Активировать» в форме бизнес-процесса или где прочитать про нее.
1. Возможно, уже не вспомню. Если при расчете перебираются все записи набора — то упущение, если идем по выборке, то все нормально, просто пропустим записи не вошедшие в перерасчет.
2. В реальности таких документов нет. Как правило регистратор пишет движения по одному виду расчета или по одному сотруднику и перерасчеты очень удачно помогают зависимости контролировать.
3. В синтаксис-помощнике:
БизнесПроцессОбъект.<Имя бизнес-процесса> (BusinessProcessObject.<Имя бизнес-процесса>)
АктивироватьИнтерактивно (ActivateInteractively)
Синтаксис:
АктивироватьИнтерактивно()
Описание:
Выполняет интерактивную активацию бизнес-процесса. Это приводит к возникновению события ОбработкаИнтерактивнойАктивации. Если обработчик этого события не изменит стандартную обработку то, бизнес-процесс автоматически отбирает все невыполненные задачи для текущего пользователя и вызывает для каждой из них метод АктивироватьИнтерактивно. Текущий пользователь выбирается из параметра сеанса, который назначен в свойстве Исполнитель у задачи, связанной с данным бизнес-процессом. Использование этого метода позволяет, например, при создании бизнес-процесса сразу приступать к выполнению заданий, выданных текущему исполнителю, если таковые имеются.
Доступность:
Сервер, толстый клиент, внешнее соединение.
2. Что значит «регистратор пишет движения по одному виду расчету»? В РР данные записываются посредством набора, нельзя же записать 2 строки набора из 100, не записывая остальные 98? То есть зарегистрируются перерасчеты для всех 100 строк при записи документа?
3. Здесь я совсем запутался. по шагам:
а) «приводит к возникновению события ОбработкаИнтерактивнойАктивации» — читаю СП: «В режиме запуска УправляемоеПриложение не вызывается.»
б) «Использование этого метода позволяет, например, при создании бизнес-процесса сразу приступать к выполнению заданий, выданных текущему исполнителю» — а просто если стартовать процесс, то нельзя что ли сразу приступить?
В общем, не понимаю что-к-чему…
2. Имею в виду, что обычно таких универсальных документов в реальности не бывает. Бывает документ «Больничный» — он по одному сотруднику ну и т.п.
3. Я тоже, в УФ не работает. Зачем надо — не понятно. Думаю глубокая мысль была заложена, надо долго медитировать.
Здравствуйте, Павел! Вопрос по передаче данных табличной части (ТЧ) документа в форму подбора. Будет ли считаться ошибкой, если данные ТЧ передавать в форму подбора как параметры, без использования временного хранилища (для каждой строки ТЧ формировать структуру, помещать в массив, а массив передать как параметр. И наоборот: результат подбора передать в виде массива в документ с последующей обработкой)? Спасибо
Будет считаться ошибкой. Так как Вы с сервера на клиент затащите все ТЧ, да еще ее и конвертируете в массив или структуру. Зачем это делать? На сервере есть все данные, они автоматом конвертируются в данные формы.
Павел, здравствуйте!
Решаю задачу 8 по подготовке к аттестации.
Использую платформу 8.3.4.437 , конфигурация без использования режима совместимости, интерфейс Такси.
Пытаюсь выполнить пункт «Необходимо в форме бизнес-процесса отображать список связанных задач и карту маршрута.
Карта маршрута должна обновляться при выполнении задач.
» Никак не получается, чтобы карта маршрута обновлялась при выполнении задач. Ваш пример так же не обновляет карту маршрута Бизнес-процесса 2. Похоже на ошибку платформы. Как поступать в таком случае на сертификации?
Это ошибка платформы. Как поступать? Написать в комментарии к решению, что у них в платформе ошибка.
То же самое озвучил преподаватель курса в 1С УЦ №1 — что ошибка платформы и надо иметь в виду. Был на курсах недели полторы назад.
Карта маршрута в обработке будет обновляться по кнопке в обработке, если сделать из клиента двойной вызов сервера. В первом вызове очистить Реквизит графической схемы, а во втором загрузить.
&НаКлиенте
Процедура Обновить(Команда)
ОчиститьКартуНаСервере();
ОбновитьКартуНаСерврере();
КонецПроцедуры
&НаСервере
Процедура ОчиститьКартуНаСервере()
Карта = Новый ГрафическаяСхема;
КонецПроцедуры
&НаСервере
Процедура ОбновитьКартуНаСерврере()
Если НЕ БП.Пустая() Тогда
Карта = БП.ПолучитьОбъект().ПолучитьКартуМаршрута();
КонецЕсли;
КонецПроцедуры
// Не оптимально, но работает :)
Первая задача.
1. Ошибка.
Движения.СтоимостьТоваров.Очистить();
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Записать();
Иначе
МоментИтогов = МоментВремени();
КонецЕсли;
Если зайти во вчерашний документ отгрузки, который списал весь товар, и сдвинуть дату на час вперед — то стоимость будет = 0. Если нажать «провести» еще раз — то стоимость будет опять корректной.
Вывод — надо записывать пустой набор всегда.
2. «Один регистр — один показатель» — это правило работает только если набор измерений разный? То есть применительно к первой задаче, если бы стоимость считалась тоже в разрезе складов, то второй регистр заводить не нужно было бы?
3. Почему в СКД используется два набора вместо одного запроса с соединением двух таблиц? Какие За и Против?
4. Почему в отчете себестоимость вычисляется не в запросе а через вычислимые показатели? Какие За и Против?
5. Если запрос без итогов, то чем хуже обход таблицы значений вместо использовани выборки? По мне так одно и то же.
Спасибо.
1. Да. Уже не раз тут обсуждали. Если мы принимаем во внимание, что пользователь может менять дату/время документа, то движения нужно чистить всегда при перепроведении документа. На экзамене — это не считается ошибкой.
2. Это аксиома. Не применительно к задаче. Это принцип проектирования регистров. Если остатки товаров по складам необходимо вести и в натуральном и стоймостном выражении, то в регистре нужно заводить 2 ресурса.
3. Это рассказывают на продвинутом курсе для программистов. Разница в том кто делает соединение скуль или сервер 1с.
4. См 3
5. > чем нехорош
>
> Запрос.Выполнить().Выгрузить();
>
> по сравнению с
>
> Запрос.Выполнить().Выбрать();
Запрос.Выполнить().Выгрузить() возвращает объект ТаблицаЗначений или ДеревоЗначений.
Запрос.Выполнить().Выбрать() возвращает объект ВыборкаИзРезультатаЗапроса.
Разработка любых механизмов платформы ведется исходя из некоторой типовой методики их использования.
Типовая методика работы с запросами предполагает, что основным, «естественным» методом работы является получение выборки из результата запроса и ее обход. То есть так надо поступать в подавляющем большинстве случаев.
Также типовая методика работы с запросами допускает вспомогательный, «противоестественный» если хотите, метод работы, когда результат запроса выгружается в таблицу значений и там дополнительно обрабатывается или анализируется.
Как уже говорилось выше, второй способ обычно используется в тех случаях, когда данные, полученные запросом, нужно показать пользователю в форме (сразу же выгрузить в реквизит формы такого типа) или в редких случаях, когда требуется дополнительная обработка результата запроса, которую трудоемко выполнить в самом запросе.
Такой сценарий работы имеют в виду разработчики платформы.
По этой причине объект ВыборкаИзРезультатаЗапроса «заточен» только под быстрый перебор записей, полученных в результате запроса, и не содержит ничего лишнего. В числе прочего осуществляется кэширование выборок очень большого размера на диске.
Объект ТаблицаЗначений гораздо «тяжелее» и заточен совершенно под другие задачи. Например, он содержит специальные механизмы, ориентированные на быстрый поиск данных , расчет итогов, свертку и т.д. Выгрузка результата запроса в таблицу значений это «отдельное упражнение» для системы, требующее затрат ресурсов.
Поэтому если вы разрабатываете простую программу для себя, то, наверное, нет разницы, что использовать.
Но особенность разработки в 1С:Предприятии заключается в том, что никогда не знаешь, в какой момент твоя «программа для себя» превратится в тиражное прикладное решение и будет работать под серьезной нагрузкой. Поэтому лучше сразу же писать методически правильно, чтобы потом не пришлось переписывать все заново, т.к. исправление уже существующих «неправильных» запросов может быть сравнимо по трудоемкости с написанием всей программы заново.
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=539617#539617
Опять немного не въехал.
Стартовая задача №1 Подзадача Отчет (СКД)
Зачем в отчете мы опять рассчитываем себестоимость, если она уже рассчитана в регистре?
Разве у нас себестоимость по складу рассчитана?
Действительно! Классный ход)))
Павел, скажите, а почему во второй стартовой задаче вы во всех регистрах накопления делали несколько показателей, ведь в самом начале сказали правило: «Один показатель — один регистр»?
Что касается партий вместе с остатками — тут я понимаю, вопросов нет, всё красиво решается и без проблем.
А вот с продажами не очень — зачем в них хранить себестоимость, если мы можем получить её из регистра остатков, связав по регистратору и номенклатуре.
Вопрос:
тут какой вариант предпочтительнее
1)делать связь из нескольких таблиц через запрос\СКД
или
2)по возможности хранить всю необходимую информацию в регистре, чтобы сразу её без лишнего гемора вытягивать?
Просто, по сути ведь получается дублирование данных.
Мы знаем сколько продали товара? Знаем
Знаем себестоимость проданного товара? Знаем
Так зачем эту себестоимость дополнительно хранить еще в одном регистре?
Не путайте слово «показатель» со словом «ресурс». Остаток товаров можно измерять в штуках, а можно в деньгах — это один показатель: остаток товара, а единицы измерения разные.
Себестоимость продаж нельзя брать из регистра остатков. Не каждое движение-расход обозначает продажу, сумма списанного товара может не равняться себестоимости продажи (брак, скидки и пр.)
Я думаю, Вам стоит подтянуть знания по предметной области.
Да, я думал над этим (брак, скидки и пр.) — но ведь в задаче об этом ни слова, поэтому и спросил.
Спасибо, что все доступно разжевали :)
Павел, здравствуйте!
Не до конца понимаю Ваше решение.
Стартовая задача №1 подзадача контроль остатков.
В тексте задачи сказано:
«При продаже себестоимость товара рассчитывается как средняя по всей компании в целом, и проверяется остаток на складе, с которого производится отгрузка.»
т.е. по сути, если выкинуть момент про себестоимость, то получится след.:
«При продаже товара проверяется остаток на складе, с которого производится отгрузка.»
Вы говорите, что «оперативное проведение и контроль остатков в режиме реального времени – это не одно и то же».
Также Вы говорите, что «Часто нужно продемонстрировать владением методики оперативного проведения»
Во всех методичках пишется, что делать контроль остатков при неоперативном проведении нет никакого смысла.
Вопрос: будет ли на экзамене считаться ошибкой (на примере данной задачи), если я вставлю заглушку на расчет остатков при неоперативном проведении?
Отвечаю на вопрос в последнем абзаце: не знаю, а зачем эта заглушка?
На все остальное, рекомендую ознакомиться: http://1c.chistov.pro/2013/07/blog-post_25.html
Вопрос был только в последнем абзаце :)
Какой смысл применять контроль остатков при неоперативном проведении?
Контролировать остатки нужно всегда. Если вы запретите работать задним числом, тогда не нужно, а иначе как?! Сегодня купили 10 ложек, и позавчера продали 20. Что будет в регистре? Полная ерунда. А себестоимость как считать? А партии?
Если запрещаем проводить задним числом — это понятно.
А если не запрещаем — какой смысл в расчете остатков задним числом?
Допустим позавчера у нас было 10 ложек. Сегодня продали 10. Теперь задним числом, т.е. вчера, мы продаем 5 ложек. Итого получается остатки будут иметь след.вид:
10 (было на остатках позавчера)
5 (осталось после продажи вчера, которая введена зад.числом)
-5 (осталось после продажи сегодня)
Зачем нужно контролировать остатки при проведении задним числом (неоперативно), если это не гарантирует нам корректность учета?
Ведь все равно получается такая же ерунда при расчете себестоимости и партий.
Корректность учета при вводе документов задним числом обеспечивается механизмом последовательностей.
Павел,здравствуйте!
Вопросы по первому видео:
1) Есть требование к сдаче: Выгрузка результата запроса в промежуточную таблицу (например, в таблицу значений) без необходимости — 1,0 балл.
На 45 минуте вы выгружаете результат запроса в таблицу значений. Не пересекается ли это
с требованиями по сдаче экзамена? За это не снимут 1 балл?
2)Вы не индексируете поля во временных таблицах при построении запроса к ТЧ документа. Это правильно? Дело в том,что во многих решениях я встречаю индексирование полей врем таблиц..
Спасибо.
Здравствуйте.
1 Не имею возможности пересматривать видео. Приведите текст — посмотрим. А требование о котором Вы говорите, чаще всего применяют к тем, кто вместо выборки начинает перебирать строки ТЗ, в которую предварительно выгружают результат запроса.
2 Индексирование — вещь субъективная. Иногда время на построение индексов уйдет больше, чем на простой перебор.
1.По первому вопросу:
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст =
«ВЫБРАТЬ
|
ПродажаТоваровСписокТоваров.Номенклатура,
| СУММА(ПродажаТоваровСписокТоваров.Количество * ПродажаТоваровСписокТоваров.Коэффициент) КАК Количество,
| &Склад,
| &Период,
| &ВидДвижения
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.ПродажаТоваров.СписокТоваров КАК ПродажаТоваровСписокТоваров
|ГДЕ
| ПродажаТоваровСписокТоваров.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| ПродажаТоваровСписокТоваров.Номенклатура
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДокТЧ.Номенклатура,
| ДокТЧ.Количество,
| ДокТЧ.Склад,
| ДокТЧ.Период,
| ДокТЧ.ВидДвижения
|ИЗ
| ДокТЧ КАК ДокТЧ»;
Запрос.УстановитьПараметр(«Ссылка», Ссылка);
Запрос.УстановитьПараметр(«Склад», Склад);
Запрос.УстановитьПараметр(«ВидДвижения», ВидДвиженияНакопления.Расход);
Запрос.УстановитьПараметр(«Период», Дата);
РезультатЗапроса = Запрос.Выполнить();
Движения.ОстаткиТоваров.Загрузить(РезультатЗапроса.Выгрузить());
Движения.Записать();
Это самый быстрый способ формирования движений. ТЗ здесь нет, данные выгружаются сразу в набор записей.
Здравствуйте Павел! У меня вопрос по запросу в документе Расходная Накладная, когда Вы получаете временную таблицу с товарами Вы применяете выборку к табличной части документа РасходнаяНакладная, а затем используете «Где» и отбираете по Документ.Ссылка = &Ссылка. Насколько я понимаю таким образом выбираются сначала все документы с их Табличными частями, а уже только потом применяется фильтр «Где» и соответственно с ростом ИБ скорость выполнения запроса будет расти. Можно ли использовать следующую конструкцию?
Запрос.Текст =
«ВЫБРАТЬ
| ТабТоварыИУслуги.НомерСтроки,
| ТабТоварыИУслуги.Номенклатура,
| ТабТоварыИУслуги.Количество,
| ТабТоварыИУслуги.Коэффициент,
| ТабТоварыИУслуги.Цена,
| ТабТоварыИУслуги.Стоимость,
| &Склад КАК Склад
|ПОМЕСТИТЬ ВТ_Товары
|ИЗ
| &ТоварыИУслуги КАК ТабТоварыИУслуги
|;
…
Запрос.Параметры.Вставить(«ТоварыИУслуги», ТоварыИУслуги.Выгрузить());
Есть ли смысл в такой конструкции или же это не оптимально?
Здравствуйте.
Не совсем понятно где у меня выбираются все документы. Приведите текст запроса.
Ваш вариант очень не эффективен, ты создаете временную таблицу, в то время как данные уже есть в базе, то есть по сути дублируете данные в базе. Имейте в виду, что временная таблица физически создается во временных файлах на сервере 1С:Предприятия.
Задача номер 1 по Оперативному учету. Документ ПродажаТоваров ОбработкаПроведения Ваше решение.
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст =
«ВЫБРАТЬ
ПродажаТоваровСписокТоваров.Номенклатура,
СУММА(ПродажаТоваровСписокТоваров.Количество * ПродажаТоваровСписокТоваров.Коэффициент) КАК Количество
ПОМЕСТИТЬ ДокТЧ
ИЗ
Документ.ПродажаТоваров.СписокТоваров КАК ПродажаТоваровСписокТоваров
ГДЕ
ПродажаТоваровСписокТоваров.Ссылка = &Ссылка
СГРУППИРОВАТЬ ПО
ПродажаТоваровСписокТоваров.Номенклатура
;
Это практически самое начало обработки проведения. Вы тоже помещаете ТабличнуюЧасть документа во временную таблицу, чтобы потом быстрее с ней работать в запросах. Меня здесь смущает «ГДЕ». Разве время выполнения такого запроса не будет увеличиваться с ростом базы? Поэтому я и подумал что лучше будет делать выгрузку ТЧ документа по временную таблицу чтобы также потом использовать её в дальнейших запросах.
Нет, с ростом базы увеличиваться время выполнения запроса не будет.
Здравствуйте.
В условии к первой задаче описано разделение номенклатуры на услуги и товары — в решении на видео, данное требование не выполнено…
Здравствуйте.
Мы предполагаем, что подобные задачи слушатели курса могут без труда решить самостоятельно.
Здравствуйте! Вопрос по задаче №1. В свойствах элемента ЕдиницыИзмерения табличной части СписокТоваров у меня почему-то нет «Связи параметров выбора». Что можно сделать, что оно появилось? У справочника владелец есть, версия 8.2, показаны все свойства элемента
ой, всё, можно не отвечать)
Добрый день, Павел.
Предварительно, хочу сказать спасибо за ресурс http://chistov.spb.ru/.
Приобрел курс с целью разбора задач по расчету заработной платы.
В первую очередь, на всякий случай, решил просмотреть разбор задач по оперативному учету, вдруг узнаю что-то новое.
После просмотра появились вопросы:
1. При решении первой задачи вы акцентировали свое внимание о требовании списывать стоимость полностью при совпадении количества остатка с количеством продажи.
Мне кажется данное правила очень существенное, так как оно позволяет решить проблему копеек при делении. И кстати при расчете стоимости вы использовали формулу расчета: Количество / КоличествоОстаток * СтоимостьОстаток., вот такая формула может привести к появлению копеек. Евгений Гилев рекомендовал использовать формулу Количество * СтоимостьОстаток / КоличествоОстаток.
2. При решении второй задачи, вы сделали Запись() (очистку движений по остаткам) только в случае оперативного проведения.
Мне кажется, что очистка и запись должна производиться по умолчанию вне зависимости от режима проведения т. к. если зайти в документ оформленный днем ранее и изменить дату на 1 секунду и перепровести в результат запроса попадут движения этого документа, т. к. режим проведения будет неоперативный а момент времени будет включать движения документа.
3. В СКД вы используете связь НаборовДанных и производите добавление вычисляемых полей.
Считается ли ошибкой связь виртуальных таблиц в одном наборе данных .
1. Математически моя формула не даст погрешность при списании последней единицы: 1 списываем / 1 в остатке (итого деление дает нам 1) * Стоимость => стоимость гарантированно спишется при полном списании количества.
2. Очень подробно тут: http://1c.chistov.pro/2013/07/blog-post_25.html
3. Нет. Но нужно понимать, что связь в запросе отрабатывает на SQL сервере, а в СКД на сервере 1С:Предприятия.
Задача 6, по ДопНачислениям. Если в документе №9 удалить премию (первые две строки) и оставить только компенсацию, она не рассчитается. Выложите, пожалуйста, Ваш работающий вариант.
Уберите условие на результат запроса: Если Не РезультатЗапроса.Пустой() Тогда
Еще один вопрос.
Определение момента времени — оперативное проведение/неоперативное проведение. Мы записываем пустой набор, то есть тем самым для системы наш документ как-бы не формирует движения? Я правильно понимаю? Здесь для меня тонкий момент. Если можно разъясните поподробнее.
Очень подробно: http://1c.chistov.pro/2013/07/blog-post_25.html
По задаче № 2 (списание по ФИФО/ЛИФО).
Вы реализовали контроль остатков непосредственно при списании товаров по себестоимости. В терминах 1С это «старый метод».
Если так сделать на экзамене не будет ли минусом, то что не использован «новый метод»? Или все равно работает правило, что явно не описано, то можно не делать?
Рекомендую почитать требования к сертификации. Недавно по 8.3 вышли: http://www.1c.ru/rus/partners/training/questions.htm
Приветствую, Павел! Сдал сегодня. С первого раза и без ошибок. Интересно, что у меня при этом нет ни одного дня опыта работы программистом 1С.
Мне очень понравился процесс подготовки. Я буквально мог наблюдать, как я рос от задачи к задаче. Я благодарю Вас за качественный продукт.
Всем удачи!
Спасибо!