Продвинутый курс. Решение ДЗ №1
30.10.2010
комментария 44
Эта запись посвящена второму потоку продвинутого курса.
Представляем решение первого задания продвинутого курса
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
По поводу применения справочника- думаю этот метод не обоснован на практике . На мой взгляд – легче просто создать свой регистр сведений с нужными измерениями и в нём вести логирование ( я на работе так и сделал , логирую кучу событий и доволен )
Да, регистр сведений + справочник – лучшее решение.
Примерно как расширенная аналитика в УПП.
Даааа…. До создания справочника как-то не додумалась…
А 50 символов-то для наименования не хватило :)
Really? Нужно проверить :)
смотрю решение…
вопрос1. Можно просто выгрузить ТЧ в ТЗ. узнать количество строк. поместить к-во в переменную. Потом свернуть её по номенклатуре. снова получить количество строк. если оно различается, значит дубли есть.
Да, можно. Но мы не скажем пользователю в какой конкретно номенклатуре ошибка.
А если в документе 1000 строк?
Когда предлагалась версия с регистром сведений, Вы сказали что все равно был бы необходим справочник, который выступал бы измерением РС. Зачем? Ведь в качестве измерения можно использовать ссылку документов.
Все понял…Вопрос снят
и всё же зачем?
Мне тоже не понятно.
Измерение – ссылка на справочник.
Ресурсы – документ, номенклатура, старая цена, новая цена.
Дело в том, что в поле Данные ЖР нужно класть ссылку. Нельзя положить ключ записи регистра сведений (вообще этот ключ не постоянен).
Поэтому создается служебный справочник, который однозначно характеризует запись в регистре.
В общем ясно. Проблема сопоставления данных из ЖР и тем что изменилось.
Мне вот что не понятно, зачем так накручивать, если мы хотим знать что изменилось и нам для наших целей недостаточно возможностей ЖР, то зачем туда вообще писать тогда? Писали бы в регистр с измерениями Дата + Документ + Номенклатура ресурсы ценаСтарая, ценаНовая? И отчет бы просто строился. А так получается и в ЖР написали и объектов кучу создали.
На практике все зависит от требований к учетной системе, к безопасности. Как раз для этих требований и нужно писать данные в ЖР.
А чтобы записать дополнительные сведения придется создавать служебные объекты..
+1
Лично для меня очень ценным оказался пример использования в пакете запросов таблицы значений через параметр. И ведь передавал таблицы в запрос для множественного отбора, а для создания временной таблицы не догадывался, всё использовал менеджер ВТ. Отдельная благодарность Евгению за демонстрацию подобных приёмов!
Постараемся и дальше вас радовать приемами конфигурирования и отладки :)
Кстати, насчет временных таблиц. Раньше в версии 8.1 требовалось для объекта запрос создать менеджер ВТ программно: Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Судя по листингу решения ДЗ теперь это делать не нужно?
В пакете запросов не нужно создавать менеджер.
А если есть желание, чтобы ВТ жила какое-то время, то нужно использовать менеджер ВТ.
Т.е. после выполнения пакета запросов, если нет менеджера ВТ, все созданные в пакете ВТ исчезнут и не будут доступны в следующем тексте запроса, даже если этот текст пишется тому же объекту Запрос, что раньше выполнял пакет, так?
Именно.
Это решение легко обойти – изменить цеы с отменой проведения, а потом – провести..
Да, таким образом можно обойти.
Но в ЖР будет видно, что с этим документом “шаманили”.
Тем не менее, этот момент нужно иметь ввиду.
А будет ли, как в Базовом, выгрузка с авторским решением? Обычно свое решение существенно отличается от авторского, а последующие ДЗ базируются на результатах предыдущих…
Обновление вышло :)
Функция записи в журнал со статус транзакции транзакционная все равно пишет в журнал эти данные, только указывает в статусе транзакции “отменена”, поэтому при построении отчета надо учитывать этот факт и в фильтре добавить:
Фильтр.Вставить(“СтатусТранзакции”, СтатусТранзакцииЗаписиЖурналаРегистрации.Зафиксирована);
Ок, спасибо, Илья!
Мои ошибки по ДЗ 1:
Группировку по пользователям не делал, отчет выводил просто список изменений, лишь отсортированный по пользователю. Как следует из решения, как раз на итогах возник целый ряд проблем, которые пришлось попутно решать.
Запись в ЖР сведений о том, какие цены и на что поменялись, производил в поле ЖР “Комментарий”. Получилось совсем не так красиво, как у Евгения.
Вопросы по ДЗ:
Нельзя при просто типизировать уже существующие колонки таблицы значений, чтобы не заниматься лишней загрузкой/выгрузкой?
Что будет с данными ЖР, которые удаляются из ИБ (например, элементы справочника “ИзмененияЦен” удалятся, а записи ЖР отсанутся), ведь при контроле ссылочной целостности ЖР не учитывается, так? При отображении ЖР увидим в поле Данные “Объект не найден…”?
К сожалению, Тип у колонки ReadOnly.
При физическом удалении элемента справочника, в поле данные будет содержаться “Объект не найден(GUID)”. А вот информация в поле представление останется неизменной.
Видеоурок 11.
Слегка ввели в заблуждение :) метод СкопироватьКолонки() не копирует содержимое колонок, а только структуру таблицы значений. Т.е. в любом случае скопировать данные не получилось бы.
Спасибо, fixed :)
Видеоурок 5.
Сказано, что в зависимости от уровня настраивается детализация записи в журнал. Т.е. получается, что если программно вызывать метод ЗаписьЖурналаРегистрации() и указывать уровень, который согласно настройкам ЖР в конфигураторе не регистрируется, то такая запись (даже программная) в журнал не попадет?
Да, именно так.
Возник один вопрос: Евгений, вы дубли номенклатуры определяете через добавление колонки с единичкой и сверткой тз. Все тоже самое можно сделать через запрос. Вы сознательно сделали через свертку тз кодом, потому что так быстрее?
Через запрос?
Можно, но будет решаться другая задача :)
Ведь в событии перед записью документ еще не записан.
То есть запросом вы будете обращаться к прошлому состоянию документа (если он ранее был записан).
Итого решите следующую задачу: нельзя записывать документ, если в прошлый раз в него ввели дубли :)
Пользователь повесится ))
Евгений, я имел ввиду, что можно было тз скинуть в темповую таблицу, сгруппировать по номенклатуре, посчитать количество дублей и отобрать только ту номенклатуру, где оные дубли есть. Вы все тоже самое делаете, но только кодом на языке. Вот я и спросил – с чем связан этот выбор? В этом есть что-то сермяжное? :)
Теперь я понял в чем был вопрос.
На самом деле однозначно ответить не могу, какой алгоритм будет отрабатывать быстрее.
Ведь на создание временной таблицы требуются определенные накладные расходы.
Кажется, что на небольшом количестве строк в документах выиграет вариант без запроса.
Но для достоверности неполохо бы провести эксперименты :)
Если Вас не затруднит по возможности давайте ссылку на архив целиком. не очень удобно скачивать по отдельности. спасибо.
DM используете?
Решения ДЗ и сессии МГ не планируем выкладывать одним архивом..
не использую. он меня раздражает.
ну коль не планируете, не велика потеря. буду качать как ранее по 1му файлу.
По мне так, довольно сомнительно использование справочника. Лучше уж лишние строки писать в ЖР.
В чем неудобство использования ЖР – нельзя указать более одной ссылки.
А это нам требуется. Как минимум нужно знать ссылку на документ и ссылку на номенклатуру.
Хотя…можно GUID запихать в комментарий, а потом раскодировать, это тоже вариант.
Поддерживаю Илью. У нас одна и та же информация хранится в двух местах.
Информация разная, но хранится в двух местах.