Отчет предназначен для вывода списка документов, в табличной части "Товары" которых используется выбранная номенклатура.
Доступные поля отбора: Номенклатура, Организация, признак проведения документа.
В список документов для поиска попадают только те, которые содержат табличную часть «Товары», а также реквизит Организация.
Поиск номенклатуры происходит только по табличной части «Товары» по колонке «Номенклатура».
Отчет универсальный, пригоден для использования даже в самописных конфигурациях, так как не использует процедур и функций общих модулей.
А почему нельзя использовать стандартный механизм поиска ссыдок?
(1) chmv, Стандартный механизм ищет везде, а соответственно и работает медленнее. Здесь же, если Вы обратили внимание, можно делать отбор по виду документа и периоду. Думаю, что это удобно.
Может быть… Но мне вполне хватает стандартного механизма
Стандартный механизм поиска ссылок основан на системном ссылочном индексе. Ваш механизм чем отличается? Запросом дергает? В таком случае он будет работать медленнее на непроиндексированных столбцах табличных частей. Одно очко в пользу (1). Улыбнуло внутреннее соединение документа с табличной частью через ссылку. Непонятно, почему нельзя было просто воспользоваться точкой. Извините, уважаемый VasilevaHelen, но результат у вас никудышный.
Совсем забыл, что ТЧ у меня называется не товары.
(4) CagoBHuK, Я согласна, что обычный запрос с внутренним соединением выглядит глупо, но для СКД мне удобно было его использовать. Все равно из-за возможности сузить пространство для поиска, моя обработка работает быстрее универсальной. И для пользователей универсальная менее удобна, а создавалась она именно для них. Сожалею, что ТЧ у Вас не «Товары», в описании это было указано. Если будет необходимость, код самому подправить не сложно.
(6) как быть, если в каждом документе ТЧ называется по-разному? Если хочется сузить пространство, используйте прямой запрос к SQL, тогда у Вас и работать будет быстро, и универсальность сохранится. То, что для СКД оно удобно, не аргумент, т.к. соединение с лишней таблицей напрямую влияет на оптимальность построения SQL-запроса. Плюс ко всему я уже упомянул про индексацию, что является крайне важным элементом, Вами неучтенным.
(7) CagoBHuK, Если Вам не понравилось внутреннее соединение из-за того, что появляется лишняя таблица, то обращение через точку дает аналогичный эффект) А в данном случае, все равно необходимо использование как таблицы документа, так и его табличной части. А по поводу того, что табличные части называются по разному, так писать нужно придерживаясь хоть каких-то стандартов и работать самому потом с этим будет проще!
(8) вы постоянно игнорируете мой комментарий по поводу индексации. Это — раз. Во-вторых программист на то и программист, что предусматривает все варианты. Нигде в литературе по 1С не написано, что ТЧ должна называться именно «Товары». Называю так, как захочу. Это просто необходимо предусмотреть. А вот Вашим алгоритмом это не предусмотрено. Как и наличие двух табличных частей с «Номенклатурой» в каждой.
(9) CagoBHuK, Да согласна я с индексацией, но запросы к скулю сами пишите, если есть такая необходимость. Никто не заставляет Вас пользоваться моим отчетом и деньги за него я не требую, так что прошу любить и жаловать.
(10) в таком случае Ваш отчет — всего лишь очередной «Hello world!» Перепишите на стандартный поиск ссылок с выводом в СКД — тогда будет быстро и полезно. Все аргументы смотрите выше в моих сообщениях.
(11) CagoBHuK,))) Хорошо, я подумаю над этим, а Вам, в таком случае, советую подумать над стандартами при написании своих конфигураций.
(12) я не говорю Вам про то, что во всех моих конфигурациях все ТЧ называются иначе. Просто Вы не учитываете множество возможных вариантов, а используете «деревянные» методы. Мыслите масштабнее.
(13) CagoBHuK, В очередной раз повторюсь, что ограничение на табличную часть есть в описании!!! Масштабные мысли вылажу в коммерческом варианте.
(14) простите меня, но с такой упертостью проекту не видать коммерческой версии. Засим откланяюсь.
а мне понравилось… здорово
Работает в ут 11.3, управляемые формы?
А «критерии отбора» разве не для этого нужны? Прямо в форме списка, типовым отбором, прекрасно отбиралось и по Организации и по Номенклатуре из табличной части
(17) Работает в управляемом интерфейсе.