Базовый курс. Решение ДЗ №7
Представляем решение 7-го ДЗ.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
Спасибо за рассказ о документах-монстрах. Была мысль, что лучше проще, но больше :) Буду теперь бороться с таковыми на работе
Здравствуйте, Евгений, появился вопрос по решению ДЗ №7. В выгрузке базы с домашним заданием у меня возникает ошибка при записи элемента справочника “КонтактктныеЛицаКонтрагентов”, если поле наименование не заполнено, несмотря на процедуру модуля объекта
Процедура ПередЗаписью(Отказ)
Наименование = КонтактноеЛицо.Наименование;
КонецПроцедуры
Процедура ПередЗаписью(Отказ)
Наименование = КонтактноеЛицо.Наименование;
КонецПроцедуры
Если этот код перенести в процедуру “ОбработкаПроверкиЗаполнения”, то все работает, версия платформы 8.2.12.96.
Как правильно делать? Перенести код в другую процедуру или снять обязательность заполнения у поля Наименование
Правильнее снять обязательность заполнения для наименования.
Так как при программной записи ОбработкаПроверкиЗаполнения() не будет вызываться..
Спасибо за ответ. Вообще-то интересно, почему 1С не сделает основное представление элемента справочника по произвольному полю, а то получается дублирование информации…
Н-да, посмотрел – сдела работу над ошибками…
не догадался делать ввод на основании одним куском, да и печать была разбита на 2 части… да и по мелочи тоже косяков хватает…
С упорядочиванием в запросе интересный момент конечно. :) Я в запросе брал только ссылку последнего проведенного документа, поэтому с подводным камнем не столкнулся.
Евгений, Ваше решения – мое почтение, все четко разложено по полочкам. Но все же у меня остались маленькие вопросы:
1. Зачем все-таки в данной задаче делать два вида документа поступления товаров (авансовый отчет и поступление от поставщика)? Суть у документов одинаковая, различий – минимум, только в поле контрагент/сотрудник. Почему нельзя было обойтись одним документом с составным реквизитом? В дальнейшем же можно анализировать тип этого реквизита и однозначно понять, что за поступление – от поставщика или авансовый отчет.
2. Можно ли использовать справочник Контакты вместо документа? Если не ошибаюсь, в ЗУПе есть справочник “Заявки кандидатов”. По смыслу отдаленно похоже на справочник “Контакты”. Такая же фиксация произошедших событий. Я использовал справочник, стОит ли сразу переделать его в документ? Может дальше контакты будут использоваться более широко? Например, учет встреч с крупнооптовыми покупателями запчастей, подсчет сумм выданных откатов представительских расходов. :)
1. Если заглянуть сильно вглубь, то документы могут сильно различаться.
Например, подотчетные лица могут отчитываться за проживание в гостинице, ужин в ресторане.
Для этого нужны будут реквизиты Содержание, Дата № счет-фактуры, …
Но, этого не будет требоваться в наших заданиях, поэтому можно оставить один документ.
2. В большинстве случаев создается документ, если предполагается факт проведения. В нашем случае проведения по контактам не будет, поэтому можно оставить справочник.
Откаты выдавать не будем :))
1. При добавлении реквизита “Контактное лицо” в документе “Реализация товаров” для него имеет смысл настроить свойство “Связь параметров выбора”, для выбора только контактных лиц указанного в документе контрагента.
2. А зачем усложнять запрос используя вложенный запрос, не проще ли в условии ГДЕ написать следующее “ПоступлениеТоваровТовары.Ссылка = &Ссылка”?
3. Можно ли упорядочить по ссылке с флагом автоупорядочивание, это позволит избежать упорядочивания по Дате и Ссылке отдельно?
1. Это будет требоваться в следующем задании.
2. А о каком запросе идет речь? Ввод на основании? Вы предлагаете вначале получить ссылку на последний документ, а потом выбрать его табличную часть?
3. Да, можно.
Но в для наглядности и понимательности запроса рекомендуется использовать явное упорядочивание.
Более того, во вложенных запросах нельзя одновременно применять конструкции: Первые и Автоупорядочивание.
Да реализовать двумя запросами.
Зачем делать два обращения к СУБД, если все данные можно выбрать за одно обращение?
Такой код будет понятнее, а вопрос какой из этих вариантов будет быстрее остается открытым и нуждается в экспериментальной проверке.
Экспериментальная проверка лишней не бывает.
Но следует придерживаться правила выборки всех необходимых данных одним запросом.
Может быть в первое время многостраничные запросы будут казаться сложно понимаемыми, но с практикой вы сможете их читать не открывая конструктор.
Разумеется следует не забывать о необходимости оптимизации запросов.