Базовый курс. Решение ДЗ №7
18.02.2011
комментариев 39
Представляем решение 7-го ДЗ.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте
— залогиньтесь.
— залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись —
напишите нам на e-mail поддержки.
Сейчас пытаюсь догнать ушедшую вперед группу. Есть вопрос. Вы в решении (п.3) используете запрос. Но короче следующее решение:
&НаСервереБезКонтекста
Функция БазоваяЕдиницаИзмерения(Товар)
Возврат Товар.БазоваяЕдиница;
КонецФункции
&НаСервереБезКонтекстаФункция БазоваяЕдиницаИзмерения(Товар)
Возврат Товар.БазоваяЕдиница;
КонецФункции
Возможно, оно хуже по параметрам производительности. Объясните, пожалуйста.
Да, этот вариант хуже по производительности.
Получая поле через точку система считывает также и все остальные реквизиты и табличные части.
Запрос же выбирает только нужные поля.
Первоначально в поступлении сделал реквизит составным. Но вариант с авансовым отчетом нравится больше. Но это если смотреть в будущее. Если же дело только в печатной форме, то можно и не заморачиваться. А вот если в дальнейшем предусмотреть операции с деньгами (например, выдача денег подотчетнику), тогда да. Кстати, а может быть, предоставлять описание конечной конфигурации? Не в плане описания метаданных, а в плане функционала. К чему должны прийти в конце.
И еще. А почему бы при вводе на основании не использовать ссылку и через “ЗаполнитьЗначенияСвойств” заполнять реквизиты? Ведь реквизитов может быть и больше. И можно, в принципе, поиграться и с “*” для получения данных.
Да, такой вариант возможен.
Но придется обходить строки документа.
Решение запросом более универсальное, а ваше решение более гибкое.
Нужно выбирать из двух зол :)
Зачем обходить строки документа? Делаем так:
//заполняем реквизиты объекта
ЗаполнитьЗначенияСвойств(Объект, ПредыдущийДокумент.Документ);
//заполняем табличную часть
Объект.Товары.Загрузить(ПредыдущийДокумент.Товары);
Я имел ввиду реквизиты документа, а не ТЧ при использовании “ЗаполнитьЗначенияСвойств”. Таким образом, при сопоставлении будут заполнены нужные реквизиты и самого документа, и ТЧ
А сам запрос вот:
<code>
ВЫБРАТЬ ПЕРВЫЕ 1
ПоследнийДокумент.Товары.(
НомерСтроки,
Номенклатура,
ЕдиницаИзмерения,
Количество,
Цена,
Сумма,
СостояниеТовара
),
ПоследнийДокумент.Ссылка КАК Документ
ИЗ
Документ.ПоступлениеТоваров КАК ПоследнийДокумент
ГДЕ
ПоследнийДокумент.Контрагент = &Контрагент
И ПоследнийДокумент.Проведен
УПОРЯДОЧИТЬ ПО
ПоследнийДокумент.МоментВремени УБЫВ
АВТОУПОРЯДОЧИВАНИЕ
</code>
И я не пробовал с “*” поиграться в запросе, но наверное, это тоже подойдет. Тогда запрос еще сократится.
Хороший вариант.
Действительно универсальный и быстрый алгоритм.
>Кстати, а может быть, предоставлять описание конечной конфигурации
Подумаем над этим предложением. Спасибо.
рекв документа контрагент составной, справочники: контрагенты, физические лица(или сотрудники).
почему такой вариант даже не рассматривался?
с запросом для основания красиво конечно получилось, но отпугивают от подобного использования косяки платформы и сложность отладки… производительность требует жертв…
прикольно что вы записываете уроки с ошибками(=
Вариантов решения несколько, но остановиться нужно на одном..
Что касается получения данных, все же рекомендую использовать запросы.
Спасибо за решение! Учиться и ещё раз учиться как говорил…..:)))
Еще раз по поводу запроса нахождения последнего документа. Меня ситуация с моментом времени удивила, полез в документацию, цитирую:
“Для нескольких документов, имеющих одинаковую дату и время, последовательность их на оси событий определяется системой исходя из ссылок на эти документы. Она может не совпадать с последовательностью создания документов, и она недоступна для изменения пользователем, то есть нельзя каким-либо образом повлиять на последовательность документов внутри одной секунды или “вычислить”, что один документ создан раньше, а другой – позже.”
Получается, что в исправленном запросе из сортировки можно убрать ссылку, т.к. если документы имеют разное время, то даты будет достаточно, а если одинаковое – то все равно не гарантировано, что у более позднего документа ссылка “больше”, и что получим в результате – это дело случая.
Как я понял, момент времени можно использовать, чтобы однозначно распределить набор документов по оси времени, и этот порядок будет всегда одинаков, пока не изменяются времена и даты документов. Но определить какой из документов именно создан первым (или последним) в общем случае невозможно.
Еще больше меня удивила ситуация, когда внешний запрос выбирал данные документа, ссылки на который не было в результате внутреннего запроса. Т.е. внутренний запрос возвращает ссылку на док-т №3, а внешний запрос выбирает табличную часть док-та №1. Тут ведь уже не важно каким образом был получен результат во внутреннем запросе, можно из-за неоднозначности момента времени получить не тот документ, но табличная часть должна была выбраться именно от полученного документа в любом случае. Тут я объяснения не нахожу, можете пояснить такую ситуацию подробнее?
> а если одинаковое – то все равно не гарантировано, что у более позднего документа ссылка «больше», и что получим в результате – это дело случая.
Как раз это и гарантируется. Цитирую вашу цитату документации
“…последовательность их на оси событий определяется системой исходя из ссылок на эти документы…”.
То есть в рамках одной секунды документы строго упорядочены по ссылке.
Дальнейшая цитата документации, говорит лишь о том, что ссылку нельзя однозначно использовать для идентификации документа на временной оси.
Если сделать краткую выжимку из цитируемой документации, то получится: документы нужно упорядочивать сначала по дате, затем по ссылке.
Дата + Ссылка соответствует моменту времени, поэтому это поле может однозначно использоваться для сортировки (если бы не было глюков платформы).
>Т.е. внутренний запрос возвращает ссылку на док-т №3, а внешний запрос выбирает табличную часть док-та №1.
К сожалению, сейчас нет доступа к решению ДЗ№7, поэтому не могу понять о чем идет речь.
Если можно расшифруйте о чем идет речь, либо через двое суток смогу пересмотреть решение и дам ответ…
>То есть в рамках одной секунды документы строго упорядочены по ссылке.
Да, упорядочены, и порядок этот при любых выборках будет всегда один и тот же, но как этот порядок соответствует порядку создания пользователями этих документов – не понятно. То есть, допустим у нас есть несколько документов в одной секунде. Мы создаем новый документ и помещаем в ту же самую секунду. Насколько я понял, заранее нельзя сказать какое место займет новый документ среди уже имеющихся в этой секунде. Да и в Вашем уроке (Блок2, глава1, часть 7) тоже говорится, что принцип “позже док-т – больше ссылка” не документирован и полагаться на него не стоит.
>Если можно расшифруйте о чем идет речь, либо через двое суток смогу пересмотреть решение и дам ответ…
Так затрудняюсь описать, лучше, наверное посмотреть. Части 8-9 решения. Буду ждать ждать ответа :)
> но как этот порядок соответствует порядку создания пользователями этих документов – не понятно
Порядок создания документов можно получить из журнала регистрации. Но разве он нужен для прикладных задач?
Например в 19.02.11 в 22:11 создали документ от 11.01.2011 12:18, а в в 19.02.11 в 22:12 создали документ от 31.12.2012 23:56:56. На что влияет дата создания с точки зрения бизнес-логики?
>Насколько я понял, заранее нельзя сказать какое место займет новый документ среди уже имеющихся в этой секунде
Именно так.
Но как только ссылка на документ появится, он займет свое “место” в секунде.
>Части 8-9 решения.
Ок, как только появиться более-менее стабильный интернет, дам ответ.
>Тут я объяснения не нахожу, можете пояснить такую ситуацию подробнее?
Логических объяснений здесь нет.
Налицо ошибка платформы.
Спасибо за решение!
Возможно ли выполенение 8 задания в Вашей выгрузке информационной базы? В моей базе за 7 заданий уже столько неправильного и лишнего, что проще начать сначала.
Да, такой вариант возможен.
По умолчанию при вводе новой номенклатуры создается новая единица измерения этой номенклатуры с коэффициентом 1. Почему бы для нее не создать например реквизит ОсновнаяЕдИзм(тип спр-к ЕдиницыИзмеренияНоменклатуры) и сразу вписать ее туда. Таким образом отпадает необходимость писать дополнительные запросы.
Если все-таки делать через запрос, то надо как мне кажется еще проверять на коэффициент=1.
>Почему бы для нее не создать например реквизит ОсновнаяЕдИзм
Да, это хорошее решение для удобства работы пользователя.
>Таким образом отпадает необходимость писать дополнительные запросы.
Правильно я понимаю, что речь идет о подставке основной единицы при выборе номенклатуры в документе?
Если да, то это действительно хорошо. Но мы будем заставлять пользователя указывать единицы измерения вручную.
Да все верно. Речь как раз об автоподстановке ед.изм. при выборе номенклатуры. Вручную указывать ничего не нужно, достаточно ПослеЗаписи номенклатуры, создать ее и сохранить в реквизит ОсновнаяЕдИзм. Конечно же, если ед. измерения у номенклатуры много, то пользователю рано или поздно прийдется в документе выбирать ее из списка, т.к. автоматически подставленная, она может не удовлетворять требуемой. Но в таком случае и в случае с запросом также стоит та же проблема выбора вручную. Я понимаю что решений поставленной задачи множество и наверное нас таким образом потихоньку приучают писать запросы :)
P.S. Для себя решил, что если какие-то ошибочки появляются, я у себя исправляю, и продолжаю работу в этой же базе. Ведь очень важно пройти самому весь цикл нуля, накопить багаж знаний и наступить на возможные грабли :)
Да, выполнить все задания в своей базе это ценный опыт.
Эх, да, с каждым азом смотря на решения, думаешь что все реализовал, а оказывается столько мелочей…
Учиться, учиться и еще раз учиться….
Да и еще такой вопрос, я случайно файл со своим 7 ДЗ перепорти (Точнее я просто вместо выгрузить нажал загрузить…)
Возможно ли продолжать решения в ваших выгрузках?
Да, такой вариант возможен
Во блин, несколько часов потратил с консолью и запросом возвращающим табличную часть, но вот заменить МоментВремени на аналог Ссылка + Дата даже мысли такой не возникло. Я честно говоря решил, что я чего то в запросе напортачил, а то что это всего лишь поведение платформы… Грустно в общем-то…
Да, грустные моменты встречаются. Но разработчики о них знают и в перспективе все должно быть хорошо :)
Проверил на 13.202 релизе, на вашей выгруженной базе. Сортировка по моменту времени работает.
Значит жизнь налаживается :)
За информацию – спасибо.
У меня тоже релиз 13.202. И именно во вложенном запросе сортировка по МоментВремени не сработала.
Это уже интересно.
А если попробовать на релизе 13.205?
Обновил платформу до 13.205
Изменений не обнаружил…
Печальный факт, хорошо что есть пути обхода проблемы.
Ага, именно во вложенном и не работает. А я проверял без подзапроса :(
Не получается скачать! Выдает:
Этот файл доступен только для авторизованных пользователей
Пожалуйста авторизуйтесь для скачивания файла
Хотя я залогинен. Выход и вход не помог.
Все. Заработала авторизация.
Это были технические работы по обновлению сайта.
Сейчас все закончили…
У меня при попытке скачивания возникает страница авторизации “Этот файл доступен только для авторизованных пользователей
Пожалуйста авторизуйтесь для скачивания файла”. При этом я авторизован на сайте, вижу свой профиль. Перелогиневался и пробовал через другой браузере (IE). Основной мой браузер Opera.
В чем может быть проблема?
Это были технические работы по обновлению сайта.
Сейчас все закончили…