Базовый курс. Решение ДЗ №8
06.12.2010
комментариев 20
Представляем решение очередного задания.
Это “объемное” решение, состоящее из 27 видео-уроков.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
Скажите, зачем передаем в запрос при проведении документа “поступление товаров” дату и контрагента? Ведь можно все это получить в запросе.
Почему при проведении авансового отчета контрагнет не заполнятеся,
Можно получить и в запросе, запрос будет чуть сложнее.
Принципиальной разницы нет.
При проведении авансового отчета контрагента не заполняем, потому что его нет в документе.
Так разве сотрудник не является по сути контрагентом?
Нет, по факту поставщиком является какой-то контрагент, которого в документе мы не указываем.
Стало понятно зачем в типовых коэффициент пересчета выносят в табличную часть, спасибо.
Как и многие к сожалению не подумала про отмену проведения…
Но есть вопрос, а не будет ли оптимальней при проведении документа “КонтактСКлиентом” использовать МенеджерЗаписи вместо набора, ведь у нас всегда будет только одна добавляемая запись? И при отмене проведения если использовать МенеджерЗаписи то можно просто установить значения ключевых полей и использовать метод Удалить. Я понимаю что показанный вариант более универсальный если у нас документ делает не одну запись а несколько, но в данном конкретном случае что лучше?
Да, в этом случае можно использовать менеджер записи.
Совсем забыл сделать обработку удаления проведения в документе “Контакт”. Посыпаю голову пеплом…
Увидел небольшое противоречие в материалах второго блока, а именно в уроке 223 “Физическая таблица регистра накопления” вы говорите, что не стоит обращаться к физической таблице регистра без крайней на то необходимости. При решении домашнего задания наоборот используете обращение к физической таблице, хотя эту же задачу можно решить с помощью виртуальных таблиц. Вопрос в том как все таки лучше, использовать ВТ или обращаться к ФТ?
Хороший вопрос.
Действительно это одна из не многих задач, которую эффективно решать именно с помощью физической таблицы.
Давайте рассмотрим возможные варианты
1. Обращение к ВТ Остатки. Но мы знаем, что эта таблица не возвращает нулевые записи. Поэтому если остатка сейчас нет (а раньше был) таблица будет пуста.
То есть этот вариант будет ошибочным.
2. Обращение в ВТ Обороты. Для регистра вида остатки эта ВТ всегда делает обращение в физической таблице, но при этом производятся дополнительные вычисления.
Поэтому вариант не оптимальный.
3. Обращение в физической таблице и выбор первой записи, удовлетворяющей условию. Самый быстрый вариант.
Но здесь желательно не забыть поставить условие на активность записей (чего я не сделал).
Во всех остальных случаях правильно обращаться к виртуальным таблицам.
На мой взгляд, при проверке первого контакта в документе КонтактСКлиентом имеет смысл изменить запрос, добавив проверку на то, что период записи должен быть меньше даты документа, поскольку именно в этом случае контакт можно считать первым. И соответственно при установке отбора на набор записей регистра сведений устанавливать его не только по Контрагенту, но и по периоду.
Вопросы.
Если уж идет такая борьба с избыточным кодом, то почему запросы к табличной части Товары при обработке проведения документов поступления вы не вынесли в общий модуль. Ведь такой прием по замене текста запроса в зависимости от вида документа уже был использован.
Для чего при заполнении коэффициента единицы измерения сначала вызвали процедуру клиентского общего модуля, а уже оттуда вызов функции серверного модуля почему сразу не вызвать функцию серверного общего модуля.
>имеет смысл изменить запрос, добавив проверку на то, что период записи должен быть меньше даты документа
Да, хорошее предложение.
>почему запросы к табличной части Товары при обработке проведения документов поступления вы не вынесли в общий модуль
Ситуация следующая.
В реальной практике структура документов все-таки различается больше, чем в наших задачах, и чтобы создать универсальный запрос приходится делать множество подстановок.
В итоге не совсем понятно будет какой запрос для какого документа будет выполняться.
Поэтому обычной практикой считается получить данные документа в модуле объекта, а далее передавать результат в методы общих модулей.
Однако, в наших примерах можно было бы и запрос вынести в общий модуль.
>Для чего при заполнении коэффициента единицы измерения сначала вызвали процедуру клиентского общего модуля
Чтобы уменьшить количество кода в модулях документов.
На одну строку :)
В противном случае в каждом документе пришлось бы писать:
ТД.К = РаботаСДокументаСервер.ПолучитьКоэффициент(ТД.ЕдиницаИзмерения);
Возможно в будущем нужно будет делать еще какие-либо действия при изменении единицы. Поэтому и был сделан вынос кода в общий модуль.
Документ “Контакт с клиентом”.
1. ОбработкаУдаленияПроведения().
Для предварительного отбора записей выполняется отбор по контрагенту. Но можно ведь ещё дополнительно отбирать по периоду. Только надо подставлять правильное значение в зависимости от периодичноси регистра. Если “В пределах дня”, то это будет НачалоДня(Дата). В таком случае набор будет состоять из одной только записи. Тем не менее, надо будет проверить реквизит “Документ”, т.к. пользователь мог вручную затереть запись, порожденную документом, и установить другой ресурс.
2. А вот аналог удаления движений при перепроведении не был выполнен. Здесь как раз отборы не помогут, т.к. пользователь мог изменить в документе дату и контрагента. Стало быть, придётся выгружать в таблицу значений весь регистр и искать там записи с соответствующим реквизитом “Документ”.
Ну, у нас-то игрушки, а как же в типовых конфигурациях?
1. Хорошее предложение.
Но оно оставляет пользователям лазейку.
Можно изменить дату документа и снять документ с проведения. Тогда запись в регистре останется.
Но самое страшное, что пользователь может с таким же успехом изменить контрагента.
Поэтому, чтобы закрыть все лазейки, придется анализировать регистр целиком. Либо делать удаление движений в событии ПередЗаписью( ), к чему я больше склоняюсь.
Ведь здесь можно анализировать режим записи и ловить отмену проведения.
2. Такую проверку тоже нужно реализовать.
Для этого можно установить отбор по старому контрагенту и дате, значения которых передать из события ПередЗаписью( ).
Спасибо за внимательный анализ!
Думаю будет не лишним запретить изменять пользователю значения реквизита Документ регистра сведений МенеджерыКлиентов.
Пожалуй да.
Можно даже на уровне прав.
Запись в регистры накопления в документах через выгрузку запроса + оптимизация запроса, при проверке были ли движения по баз.ед. измерения – это гениально ! :)
я что-то не совсем понял, зачем отказываться от регистратора а потом добавлять реквизит документ, который по сути и есть регистратор?
посидел, подумал, кажется понял )))
для того чтобы была возможность создавать записи в регистре без регистратора )
В задании сказано, что пользователи добавляют информацию непосредственно в регистр.
То есть режим записи независимый.
Вообще показанный прием встречается и в типовых (например, в ЗУП), поэтому его полезно знать..