Имющие(Having). Как реализовать виртуальную таблицу "СрезПоследних". #748764

Добрый день! Столкнулся с задачей: Есть документ "Заявка", в котором указывается какой контрагент сколько продукции будет потреблять. При проведении документ пишет запись в регистр сведений "АктуальнаяЗаявка"(доступен СрезПоследних). Сделано это потому, что по умолчанию, завтра требуется поставить столько же продукции, сколько поставили вчера(если не было подано новой заявки). Требуется определить, сколько материалов требуется для выпуска продукции за год. Остальные вещи описывать не буду(как устроен справочник "Спецификации", какие дополнительные реквизиты есть), так как к вопросу они не имеют отношения. Сейчас код выглядит так: Пока ТекущаяДата <= ДатаОкончания Цикл     Выполняем запрос к регистру(срез последних)... Такой цикл проходит 365 или 366 раз подряд. Что вызывает 365 или 366 раз запрос, что довольно долго. Пытаюсь составить запрос, в котором можно было бы выполнить аналогичные действия "СрезПоследних", но за один вызов. Имея опыт работы с другими базами данных, запрос бы выглядел так: dates   inner join requests Проблема в том, что в конструкции "ГДЕ" нельзя использовать поля группировка "МАКСИМУМ", а в конструкции "ИМЕЮЩИЕ" нельзя использовать не группированные поля. То есть в языке запросов 1С не может ни в какой части запроса быть выражение "АктуальнаяЗаявка.Период = МАКСИМУМ(АктуальнаяЗаявка.Период)" Кто-нибудь знает способ реализовать вариант как в обычном запросе?

пользуй временную табличку для нахождения максимума и её пихай в имеющие

У меня обратная ситуация. Я знаю, как написать запрос SQL, а вот как обратно? Есть идея для запроса? МАКСИМУМ надо взять для МоментВремени, а не для Дата! Потому что регистр по позиции регистратора! А максимум по МоментВремени взять нельзя! Уже пробовал.

Можно использовать прямой запрос. Можно использовать Top Правда по сравнению с той платформой можно использовать только одно поле. Но в примере вмето нужно использовать просто РеализацияТоваровУслугТовары.НомерСтроки В

Есть такая идея. Ниже запрос. Если что лишнего - я просто выкинул шелуху, оставил только основное для понимания. ВЫБРАТЬ

4+

> У меня обратная ситуация. Я знаю, как написать запрос SQL, а вот как обратно? Этот запрос к базе 1С или сторонней базе? Если сторонней, то подключайся к той базе по АДО и выполняй свой запрос. А как перевести - можешь и латинские литералы использовать, вроде select - 1С-ный язык запросов их понимает.

У меня все данные в регистре сведений. Внешних данных нет. Я попытался перевести с "языка SQL" на язык запросов 1С, но либо я плохо перевел, либо у 1С не умеет работать с ИМЕЮЩИЕСЯ в полном объеме, как это возможнго с SQL. Пытаюсь вникнуть.

На простом примере(из головы): Есть торги. Есть покупатели, есть номенклатуры. Победитель - тот кто предложил максимальную стоимость. Дано: -----------------------------------------| Клиент | Номенклатура | Предложенная цена| -----------------------------------------| Клиент1| Номенклатура1|10                | Клиент2| Номенклатура1|20                | Клиент1| Номенклатура2|30                | Клиент2| Номенклатура2|40                | ------------------------------------------ Задача: запросом определить победителей по номенклатурам. Ответ для SQL: select max(dano.client), dano.nom AS nom , max(dano.price) from dano group bu nom Результат запроса: -----------------------------------------| Клиент | Номенклатура | Предложенная цена| -----------------------------------------| Клиент2| Номенклатура1|20                | Клиент2| Номенклатура2|40                | ------------------------------------------ Нужен запрос для 1С...

А в каком это SQL, в предложении HAVING можно использовать поля по которым не группировали? Приведите пример с указанием конкретного сервера (языка запросов SQL). :)

1С прекрасно умеет работать с HAVING. Читайте документацию внимательно.

Чтобы использовать ИМЕЮЩИЕ в запросе, надо это поле сгруппировать. Пример: "ВЫБРАТЬ |    ПартииТоваровНаСкладах.Склад,

выбрать максимум(dano.client), dano.nom как nom, максимум(dano.price) из dano сортировать по nom так пройдет в твоей базе?

Ссылку на "срез последних на каждый день уже дали". Но для твоей задачи > Требуется определить, сколько материалов требуется для выпуска продукции за год. лучше использовать регистр накопления и не иметь этих проблем.

в конструкции "ИМЕЮЩИЕ" недопустимо использовать поля, не входящие в группировку (для этого примера - "dano.client") Это вопрос архитектуры конфигурации, на которое я повлиять не могу. Я только пишу внешнюю обработку. говорить "надо снимать конфигурацию с поддержки" не имеет смысла. Ведь можно выполнять запрос в цикле на каждый день. Ну и регистром накопления встает вопрос: кто будет туда писать данные? Заявка - тогда вопрос, до какого периода писать туда данные? На месяц? А если завтра поменяются данные? В общем, в конфигурации сделано довольно разумно.

Если конфа на поддержке, тогда другое дело. Я полагал, что архитектура в твоих руках. > Заявка - тогда вопрос, до какого периода писать туда данные? На месяц? Ну заявка ведь на какой-то период делается?

Нет. Звонит клиент и говорит, что с сегодняшнего дня мне надо 15 шт/день. Потом позвонит через два с половиной месяца скажет, что привози 18 шт/день

Договор на год. Но заявка будет действовать неопределенный период.

Пример запроса получения курса валюты на дату каждого документа выборки: ИЗ             (ВЫБРАТЬ ПЕРВЫЕ 1                МАКСИМУМ(Т.Период)             ИЗ

Отличный вариант! Я его уже пробовал, но у меня " МАКСИМУМ(Т.Период)" надо заменить на  МАКСИМУМ(Т.МоментВремени) , и тут платформа возмутилась на невозможность сравнения "строк неограниченной длинны и составных значений). Вероятнее всего, Момент времени является "составным значением"(структура Дата+НомерЗаписи). У меня регистр сведений по позиции регистратора , так что использовать дату не совсем корректно. Вероятность ошибки, конечно, довольно мала. Но если вдруг получится, что этим воспользуются, то в результате будет 2 записи на одну дату.

Т.е. надо на момент времени каждого документа?

Какая периодичность у РС "АктуальнаяЗаявка"?

Момент времени это Дата+Ссылка. То есть В    (ВЫБРАТЬ последние 1                Т.Период             ИЗ                РегистрСведений.КурсыВалют КАК Т                И Т.Период <= ПоступлениеТоваровУслугТовары.Ссылка.Дата Сортировать По Т.Период)) Но у регистра сведений нет регистра сведений. И ты можешь получить несколько документов на одну дату. Опять можешь применить выбрать первые или максимум.

Неа. Для каждой даты. Пример: Мне нужен срез последних на даты: 01.01.2015 00:00:00 02.01.2015 00:00:00 03.01.2015 00:00:00 ... Возможна ситуация, при которой Есть 2 документа: Документ Заявка №00-00125 от 01.01.2015 15:32:15(была создана первой) Документ Заявка №00-00126 от 01.01.2015 15:32:15(была создана второй) При этом количество продукции на 02.01.2015 00:00:00 надо взять из "Документ Заявка №00-00126 от 01.01.2015 15:32:15", так как именно его выберет срез последних.

По позиции регистратора. Прошу прощения, только заметил сообщение.

Тогда можно заменить "Период" на "Регистрато.МоментВремени", но это не есть гуд..

Нельзя. Уже определились в , что вариант сравнения "строк неограниченной длинны и составных значений" недопустимо.

А какой у регистра курса валют МоментВремени? Если он и есть то там не нужен максимум. И (КурсыВалют.Регистратор В   (ВЫБРАТЬ ПЕРВЫЕ 1               Т.Регистратор             ИЗ

Или УПОРЯДОЧИТЬ ПО     Т.Период,Т.Регистратор

может поможет ? как пример для анализа для того, чтобы построить отчет на СКД по оборачиваемости товаров мне нужны были конечные остатки на КАЖДЫЙ день, идти надо не от документа, а от регистра, и обрати внимание какие регистры задействованы для ВТ Движения, он там один, но один раз остатки, второй обороты

Вернее Выбрать Последние 1 или УПОРЯДОЧИТЬ ПО     Т.Период убыв,Т.Регистратор убыв

СКД в помощь. 2 набора данных, один - требуемые даты (с производственного календаря их раз плюнуть получить). Второй - сам срез последних. Ну и связь между наборами по дате. Метода известная и довольно несложная.

да метода известная и один из первых отчетов на СКД по оборачиваемости сделал по ней, но отчет получился тормознутым на больших периодах, то что описано в работает гораздо быстрее, а на выходе результат один и тот же