Eprst писал(а) 24. Октября 2012 :: 11:37:Весьма забавный подзапрос..
Точнее бредовая структура хранения данных:
Это да))) читай выше ответ - давнее наследие КТ-200
Цитата:У вас в алкашном справочнике может быть несколько элементов с одним товаром, но с разным производителем/импортером и , что о ужас! - с разным видом алкогольной продукции?!
Неее, Номенклатура.Алкоголь <=> АлкНоменклатура.Товар один-к-одному, т.е. косяки конечно случаются, но все отлавливается и при формировании деклы имеем "один-к-одному". Измерение в АлкРегистре - Номенклатура (не алкоголь)
Цитата:Если даже код один для каждого товара, но производитель/импортеры разные - то при функции максимум имеете кота в мешке - т.е первого попавшегося (у кого ид побольше,т.е более позднего созданного елемента справочника клиентосов) - что не верно с точки зрения учета в разрезе производители/импортеры.
Группирую все по "Номенлатура" в том числе, так что МАКСИМУМ однозначно выдаст или одно значение или Пусто
Цитата:Так что, тут структуру данных нужно менять, а не запрос, который радугу показывает оптимизировать
Однозначно согласен, но я же только еще подошел к этому))) Так сказать с полным пониманием теперь смотрю)))
Цитата:ЗЫ: ежели в этом справочнике однозначное соответствие
товар - вид продукции - импортер/производитель, то он вовсе не нужен , все эти реквизиты можно хранить в номенклатуре, если уж сделали так, то выкинуть гроупбай тогда.
Далее Производителя/Импортера буду выносить в свойства партии и организовывать парт учет.... это как со складскими площадями на след. год полегче станет, чтобы стоповать было возможно, ну а так АлкНоменклатура - нужен только как "контейнер" для алк реквизитов, т.к. конфига используется не только на алкоголе, чтобы не "засорять" Спр.Номенклатура, и хрен его знает, что там дальше придумается))) может опять акциз платить станем
Eprst, у тебя кстати эта конфига есть, если не выкинул))..когда разбирались с классом "Аля Восьмерка"