Срез последних на каждую дату в СКД и в запросе

02.11.10

Разработка - СКД

С задачей получения среза последних на каждую дату рано или поздно сталкиваются все. Безусловно, это задача достаточно просто решается запросом с соединением по максимальной дате из меньших или равных дат. Но эту же задачу можно решить и с помощью компоновки данных. Не будем рассуждать о том, какой из способов более производителен, все может зависеть от конкретной задачи.

Первый набор данных:

В качестве примера, создадим отчет по продажам, в котором отдельной колонкой будем выводить цену из прайса на дату продажи.

Создадим набор данных-запрос «ПродажиОбороты»:

ВЫБРАТЬ
    ПродажиОбороты.Период КАК Дата,
    ПродажиОбороты.Контрагент КАК Контрагент,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    ПродажиОбороты.КоличествоОборот КАК Количество,
    ПродажиОбороты.СтоимостьОборот КАК Стоимость
{ВЫБРАТЬ
    Дата,
    Контрагент.*,
    Номенклатура.*,
    Количество,
    Стоимость}
ИЗ
    РегистрНакопления.Продажи.Обороты({(&НачалоПериода)},
{(&КонецПериода)}, День, ) КАК ПродажиОбороты
{ГДЕ
    ПродажиОбороты.Период,
    ПродажиОбороты.Контрагент.*,
    ПродажиОбороты.Номенклатура.*,
    ПродажиОбороты.КоличествоОборот,
    ПродажиОбороты.СтоимостьОборот}

 

 

 

Сейчас наш отчет будет иметь следующий вид:

 

 

Теперь необходимо добавить в отчет колонку «Цена по прайсу», которая будет подтягиваться из регистра сведений «Цены номенклатуры» на дату продажи.

 

Второй набор данных:

Добавим второй набор данных-запрос «Цены», цены будем брать для фиксированного типа цен:

ВЫБРАТЬ
    &Дата КАК Дата,
    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
{ВЫБРАТЬ
    Дата,
    Номенклатура.*,
    Цена}
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
            &Дата,
            Номенклатура = &Номенклатура
                И ТипЦен = &ТипЦен) КАК ЦеныНоменклатурыСрезПоследних
{ГДЕ
    (&Дата),
    ЦеныНоменклатурыСрезПоследних.Номенклатура.*,
    ЦеныНоменклатурыСрезПоследних.Цена}

В данном наборе данных три параметра: Дата, Номенклатура и тип цен. Из низ самые интересные Дата и Номенклатура. Они будут использованы при соединении наборов данных, причем параметр данных присутствует как в параметрах виртуальной таблицы, так и в выбранных полях.

Соединения наборов:

Приступим к основной «фишке» данного метода – соединениям наборов:

 

 

Здесь самое основное правильно настроить параметры. Если указан параметр,то  СКД передает в приемник связи параметры, указанные в соединении. Значениями этих параметров будут значения соответствующих полей источника связи.

Далее добавим поле цена в ресурсы и в выбранные поля.

 

 

Результат:

Теперь можно формировать отчет. Проверим правильность работы отчета на примере «Дивана для отдыха».

 

 

В запросе:

Рассмотрим решение этой же задачи в запросе. Данная задача может быть решена как с использованием вложенных запросов, так и с помощью. временных таблиц. Попробуем решить задачу, используя временные таблицы. Сначала приведем весь текст запроса, а потом кратко разберем по частям принцип его работы.

Текст запроса:

ВЫБРАТЬ
    ПродажиОбороты.Период КАК Дата,
    ПродажиОбороты.Контрагент КАК Контрагент,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
    СУММА(ПродажиОбороты.СтоимостьОборот) КАК Стоимость
ПОМЕСТИТЬ втБезЦены
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК ПродажиОбороты

СГРУППИРОВАТЬ ПО
    ПродажиОбороты.Период,
    ПродажиОбороты.Контрагент,
    ПродажиОбороты.Номенклатура

ИНДЕКСИРОВАТЬ ПО
    Номенклатура,
    Дата,
    Контрагент
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втБезЦены.Дата КАК Дата,
    втБезЦены.Контрагент КАК Контрагент,
    втБезЦены.Номенклатура КАК Номенклатура,
    втБезЦены.Количество,
    втБезЦены.Стоимость,
    МАКСИМУМ(ЦеныНоменклатуры.Период) КАК Период
ПОМЕСТИТЬ втМаксПериод
ИЗ
    втБезЦены КАК втБезЦены
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО втБезЦены.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И втБезЦены.Дата >= ЦеныНоменклатуры.Период

СГРУППИРОВАТЬ ПО
    втБезЦены.Дата,
    втБезЦены.Контрагент,
    втБезЦены.Номенклатура,
    втБезЦены.Количество,
    втБезЦены.Стоимость

ИНДЕКСИРОВАТЬ ПО
    Номенклатура,
    Дата,
    Контрагент,
    Период
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втМаксПериод.Дата,
    втМаксПериод.Контрагент,
    втМаксПериод.Номенклатура,
    втМаксПериод.Количество,
    втМаксПериод.Стоимость,
    ЦеныНоменклатуры.Цена
ИЗ
    втМаксПериод КАК втМаксПериод
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО втМаксПериод.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И втМаксПериод.Период = ЦеныНоменклатуры.Период
ГДЕ
    ЦеныНоменклатуры.ТипЦен = &ТипЦен
АВТОУПОРЯДОЧИВАНИЕ

Данный пакетный запрос содержит три подзапроса. Рассмотрим их подробнее.

Первый запрос пакета группирует данные по периоду, контрагенту и номенклатуре и помещает их во временную таблицу втБезЦены. Далее мы будем соединять эту таблицу с таблицей цен номенклатуры и получим небольшой выигрыш в том, что соединять будем уже сгруппированные данные.

Во втором запросе пакета мы соединяем временную таблицу с регистром сведений «ЦеныНоменклатуры» при этом из регистра сведений мы выбираем МАКСИМАЛЬНУЮ дату из меньших или равных дат.  Результат этого запроса также помещаем во временную таблицу (втМаксПериод). Посмотрим, какие данные попадают в эту таблицу:

 

 

В последнем запросе пакета, мы еще раз соединяем временную таблицу с таблицей цен номенклатуры. На этот мы соединяем таблице по номенклатуре и периоду.

Итоговый результат запроса:

 

 

Как мы видим, результаты вывода цен в обоих случаях (через СКД и через запрос) оказались одинаковы.

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    121612    670    389    

711

Генератор схемы компоновки данных (СКД), написание кода схемы программно

Инструментарий разработчика СКД Платформа 1С v8.3 Конфигурации 1cv8 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

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

3 стартмани

05.02.2024    4033    25    obmailok    17    

63

Набор-объект для СКД по тексту или запросу

Запросы СКД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Есть список полей в виде текста, или запрос - закидываем в набор СКД.

1 стартмани

31.01.2024    2000    2    Yashazz    0    

29

СКД на JavaScript в 1С

СКД WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Долгое время поддерживаю web-портал, в котором появилась необходимость создавать отчеты. Просмотрев различные фреймворки на js, я решил сделать свое решение, которое позволяло бы быстро разрабатывать и добавлять новые отчеты на web-портал.

2 стартмани

11.12.2023    8155    20    John_d    25    

123

Использование менеджера временных таблиц в СКД

СКД Платформа 1С v8.3 Система компоновки данных Конфигурации 1cv8 Бесплатно (free)

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

05.12.2023    4651    PROSTO-1C    13    

61

Модель СКД

Инструментарий разработчика СКД Платформа 1С v8.3 Система компоновки данных Абонемент ($m)

DSL для работы с СКД.

1 стартмани

15.11.2023    5804    15    kalyaka    5    

86

Пользовательские настройки отчетов 1С. Часть 1. Простые и расширенные настройки

СКД Инструкции пользователю Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 Россия Бесплатно (free)

Простые приемы работы с отчетами на СКД. Что нужно знать пользователю про настройку отчетов, чтобы использовать их на полную катушку.

18.09.2023    6692    accounting_cons    5    

29

Разрыв страницы в СКД. Легко!

СКД Платформа 1С v8.3 Система компоновки данных Бесплатно (free)

Когда отчет надо разделить по страницам, это всегда проблема для разработчика. Поскольку в СКД нет стандартных вариантов, как это сделать. Нашел (на свой взгляд) самое простое и оптимальное решение.

01.09.2023    4517    KVIKS    15    

80
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Ish_2 1104 02.11.10 06:57 Сейчас в теме
Мелкие замечания.
1. На мой взгляд , лучше говорить "второй запрос в пакете" , а не " второй подзапрос".
2. Как-то надо обозначить опасность применения в запросе соединения по неравенству.
При розничной торговле с гибкой политикой цен пользователь может быть сильно разочарован таким отчетом. "В среднем " более надежно отсечь период до "Даты начала" и вначале использовать соединение с виртуальной таблицей СрезПоследних и получить цены на "дату начала" для каждой номенклатуры. А затем уже делать соединение по неравенству с регистром , используя условие для записей регистра "Где Период >= &ДатаНачала"
2. _also 484 02.11.10 09:18 Сейчас в теме
1. Спасибо, поправил
2. Ну все таки отчет приведенный в статье не имеет более общий характер. Соглашусь с Вашим мнением, но все же это уже относиться к реальным задачам. Статья - просто пример ;)
3. tormozit 7136 02.11.10 13:58 Сейчас в теме
Метод, примененный в СКД очень неэффективен, т.е. будет работать значительно медленнее, чем пакете/запросе.
CepeLLlka; egorcheg1; denis_aka_wolf; Irwin; PhoenixAOD; zqzq; echo77; AllexSoft; Gilev.Vyacheslav; theshadowco; _also; artbear; +12 Ответить
6. _also 484 02.11.10 15:10 Сейчас в теме
(3) в СКД можно добиться некоторых плюсов, если некоторые данные не нужны. У них можно установить флаги ограничений, и СКД не будет их получать. А так согласен в подавляющем большинстве случаев запрос эффективнее.
43. alex_sayan 07.03.14 10:16 Сейчас в теме
(3) не согласен. В данном конкретном случае пакетный запрос проигрывает по производительности СКД.
44. ildarovich 7850 07.03.14 11:01 Сейчас в теме
(43) Не может такого быть...
leonidol; boln; +2 Ответить
45. alex_sayan 07.03.14 11:15 Сейчас в теме
(44) почему? В данном случае создаются две временные таблицы, а это не самая производительная операция. СКД же обойдется без записи данных на диск.
46. ildarovich 7850 07.03.14 11:44 Сейчас в теме
(45) Мои умозаключения покажутся Вам такими же умозрительными, как и мне сейчас кажутся Ваши. Просто проведите эксперимент. Он, скорее всего, будет в мою пользу и Вам легче будет поверить объяснениям.
47. alex_sayan 07.03.14 12:05 Сейчас в теме
(46) по поводу производительности я уже экспериментировал, и не однократно. Может когда-то там, в далекие времена 8.1, СКД и была тормозной, сейчас это не так.
Dmitri93; +1 Ответить
4. director04 3657 02.11.10 14:13 Сейчас в теме
Спасибо, очень интересные решения. Кстати, в одной из задач на экзамене по Бух есть именно такая задача по построению отчета.
Находил иные решения на Мисте, но против данных решений - они просто монстры.
Красиво и просто
5. RailMen 823 02.11.10 14:21 Сейчас в теме
Реализация всевдо среза первых и последних записей на каждый день периода для расчета среднесписочной численности: http://infostart.ru/public/77462/
7. Ivon 673 02.11.10 16:15 Сейчас в теме
Вот тут http://infostart.ru/public/21181/ моя статья по той же теме.
8. I_G_O_R 69 02.11.10 21:40 Сейчас в теме
Запросы это хорошо , обожаю запросы :) , вот вам еще один вариант, может кто сможет еще короче написать:
ВЫБРАТЬ
	Продажи.Период,
	Продажи.Контрагент,
	Продажи.Номенклатура,
	Продажи.КоличествоОборот КАК Количество,
	Продажи.СтоимостьОборот КАК Стоимость,
	ЦеныНоменклатуры.Цена
ИЗ
	РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
			И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
			И (ЦеныНоменклатуры.Период В
				(ВЫБРАТЬ ПЕРВЫЕ 1
					Цены.Период
				ИЗ
					РегистрСведений.ЦеныНоменклатуры КАК Цены
				ГДЕ
					Цены.Период <= Продажи.Период
					И Цены.Номенклатура = Продажи.Номенклатура
					И Цены.ТипЦен = &ТипЦен
				УПОРЯДОЧИТЬ ПО
					Цены.Период УБЫВ))
Показать

indefinitum000; akmich; slige_work; grey.grouse; VooDOOPRo; euperminov; ResAndDev; zba; SP2000; arturec05; afk; anuar_medeup; SlowAndLow; nic-lyo; makar-ananev; Serg2000mr; zhelezobeton; triviumfan; Sheogorath; reboot; KiLLius; bobah_; zetovich@mail.ru; pm74; Азверин; philya; batman2004; sommid; Flashback1979SE; +29 Ответить
32. ildarovich 7850 21.04.12 18:49 Сейчас в теме
(8) Вот еще короче
ВЫБРАТЬ
	Продажи.Период,
	Продажи.Контрагент,
	Продажи.Номенклатура,
	СУММА(Продажи.КоличествоОборот) КАК Количество,
	СУММА(Продажи.СтоимостьОборот) КАК Стоимость,
	МИНИМУМ(РАЗНОСТЬДАТ(ЦеныНоменклатуры.Период, Продажи.Период, ДЕНЬ) * &Много + ЦеныНоменклатуры.Цена) 
- МИНИМУМ(РАЗНОСТЬДАТ(ЦеныНоменклатуры.Период, Продажи.Период, ДЕНЬ) * &Много) КАК Цена
ИЗ
	РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
			И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
			И (ЦеныНоменклатуры.Период < = Продажи.Период)

СГРУППИРОВАТЬ ПО
	Продажи.Период,
	Продажи.Контрагент,
	Продажи.Номенклатура
Показать

Здесь вообще один запрос. Идея в том, чтобы вместо поиска периода, на котором начинается актуальная цена, искать саму цену. Для этого подобрана функция, которая "отправляет" цену прошлого периода на свой "эшелон", высота которого зависит от древности цены. Ширина "эшелона" задается параметром "Много" - это величина, гарантированно перекрывающая диапазон изменения цены (1000000, 10000000 и т.п.). После нахождения ближайшей (нижайшей) "летящей" цены, высота соответствующего "эшелона" вычитается и цена "опускается на землю".
Можно подобрать функцию для дат, булевых и строковых значений.
Кроме краткости записи, других достоинств у запроса нет. Минусы - некоторый проигрыш по времени "классическому" запросу из-за большего объема вычислений в группировках, необходимость думать над значением "Много", работа только с простыми типами.
grey.grouse; zba; Gorr; ra9000; RibD; +5 Ответить
38. Поручик 4670 05.11.13 12:21 Сейчас в теме
(32)
Делал отчет по перемещениям товаров на основе материалов статьи. Так как в моей базе данных немного, то отчёт работал нормально. Но клиент прислал замечания.

исходная ситуация № 1
1) товар используется в документе условно 23 10 2013
2) цена на начало месяца 1796

смотрим отчет - всё ок

исходная ситуация № 2
1) товар используется в документе условно 23 10 2013
2) цена на начало месяца 1796
3) установка цен 20 10 2013 меняет цены продажи на 2000

смотрим отчет - всё ок

исходная ситуация № 3
1) товар используется в документе условно 23 10 2013
2) цена на начало месяца 1796
3) установка цен 25 10 2013!!!!!!!!!! меняет цены продажи на 2000 (то есть дата больше документа. Та же проблема если изменить дату документа установки и на ноябрь)

смотрим отчет: цена = 1796 + 2000 = 3796 (сумма цен на начало месяца и цены, установленной после документа отчета)

Времени на изучение ситуации и переделку запроса не было, поэтому взял совет из поста 8.
37. Поручик 4670 05.11.13 11:40 Сейчас в теме
Пришлось воспользоваться советом из поста (8), иначе при некоторых условиях выдавались не совсем верные цифры
61. KNOSSOS 10.07.15 15:25 Сейчас в теме
(8) I_G_O_R,
ВЫБРАТЬ
    Продажи.Период,
    Продажи.Контрагент,
    Продажи.Номенклатура,
    Продажи.КоличествоОборот КАК Количество,
    Продажи.СтоимостьОборот КАК Стоимость,
    ЦеныНоменклатуры.Цена
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
            И (ЦеныНоменклатуры.Период В
                (ВЫБРАТЬ ПЕРВЫЕ 1
                    Цены.Период
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК Цены
                ГДЕ
                    Цены.Период <= Продажи.Период
                    И Цены.Номенклатура = Продажи.Номенклатура
                    И Цены.ТипЦен = &ТипЦен
                УПОРЯДОЧИТЬ ПО
                    Цены.Период УБЫВ))
Показать

Вышел на эту тему по поисковику. Предложенный запрос очень лаконичен, но сильно просаживает производительность. Причем на файловом варианте 8.3 на порядок медленнее чем на MS SQL2012.
А вот так будет стрелять везде:
ВЫБРАТЬ
    Продажи.Период,
    Продажи.Контрагент,
    Продажи.Номенклатура,
    Продажи.КоличествоОборот КАК Количество,
    Продажи.СтоимостьОборот КАК Стоимость,
    ЦеныНоменклатуры.Цена
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
            И (ЦеныНоменклатуры.Период В
                (ВЫБРАТЬ МАКСИМУМ(Цены.Период)
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК Цены
                ГДЕ
                    Цены.Период <= Продажи.Период
                    И Цены.Номенклатура = Продажи.Номенклатура
                    И Цены.ТипЦен = &ТипЦен
))
Показать

kiblitskyda; prog1c_vl; grey.grouse; Punisher_1C; shaykhelov; cdromscsi; Jeka44; RozalievAndrey; afk; anuar_medeup; Septera1; Angel_19; Chronic; kozusenok; adva; Eeeehhhh; igee12; Simonov_NPM; ra9000; zhelezobeton; user1090556; myoker; toxa688; zetovich@mail.ru; dr2c; sergelemon; i_lo; tehas; Ivanovag123; adhocprog; +30 Ответить
62. Поручик 4670 10.07.15 22:16 Сейчас в теме
(61) Вот примерно так я и сделал года два назад в паре своих отчётов.
63. I_G_O_R 69 11.07.15 00:27 Сейчас в теме
(61) Ха! Тема еще жива))
Сам тоже по возможности пользуюсь именно вторым вариантом. Но что еще интересно, сами 1С такие запросы до сих пор не юзают, наверное не на всех СУБД такие запросы нормально работают, но я сейчас пишу только под ms sql, там отлично работают.
73. user1090556 21.02.19 10:21 Сейчас в теме
(63)
Но что еще интересно, сами 1С такие запросы до сих пор не юзают
потому что большинство пользуются конструкторами запросов. А условие
ВЫБРАТЬ МАКСИМУМ(Цены.Период)
                ИЗ
                    РегистрСведений.ЦеныНоменклатуры КАК Цены
                ГДЕ
                    Цены.Период <= Продажи.Период
                    И Цены.Номенклатура = Продажи.Номенклатура
                    И Цены.ТипЦен = &ТипЦен)

В конструкторе будет вызывать ошибку.
77. RozalievAndrey 06.05.21 09:03 Сейчас в теме
(73) В 1С 8.3.15 конструктор нормально воспринимает такое условие!
78. RozalievAndrey 06.05.21 10:34 Сейчас в теме
(8) Проверил на файловой. Торможение в сравнении с "учебниковым" - в 6 раз, причём даже на "неподвижной" базе не заметно кэширования, повторные запросы отрабатывают за такое же время.

Делал выборку по продажам, с подтягиваем из регистра периодической информации о клиенте. В базе 13к клиентов, около 100к записей в регистре продаж, 48к записей в регистре истории.

Но вот что интересно. Время выполнения практически не зависело ни в том, ни в другом варианте от дискретности запроса - нарезал я таблицу по дням или по месяцам, без разницы
9. I_G_O_R 69 02.11.10 22:04 Сейчас в теме
Кстати во втором запросе есть ошибки и недочеты;
1) в первом запросе данные группировать НЕ надо! т.к. данные из виртуальной таблицы уже сгруппированы
2) во втором запросе не учитывается типцен, поэтому он выдаст направильный результат, если есть несколько типов цен
3) в третьем запросе условие на типцен должно быть в соединении а не в условии, поэтому третий запрос вернет только продажи той номенклатуры, для который установлена цена &ТипЦен
11. Ish_2 1104 03.11.10 00:47 Сейчас в теме
(9) ух.. глазастый какой.

Смотри (10).
12. I_G_O_R 69 03.11.10 01:19 Сейчас в теме
(11) сравнивал, но на небольшой базе, использовал модифицированный запрос из (0), убрал АВТОУПОРЯДОЧИВАНИЕ и исправил ошибки, в итоге мой запрос совсем чуть-чуть быстрее, а если добавить АВТОУПОРЯДОЧИВАНИЕ, то мой запрос заметно проигрывает, прямо даже на глаз видно, не знаю с чем это связано. Буду на работе попробую, если будет время, на большой базе. Есть у нас клиент, у которого очень много типов цен, интересно на такой базе проверить. Я думаю, что в такой базе, мой запрос может показать лучшие результаты, из-за того что в запросе из (0) второй запрос по идее должен выполнятся долго, т.к. это та же проблема что и с нарастающими итогами.
13. Ish_2 1104 03.11.10 07:02 Сейчас в теме
(12) Ага. Интересно проверить и сравнить оптимальный, исправленный запрос из (0) и твой. Причем в твоем запросе , та же проблема что и с нарастающими итогами.
Если таблицу регистра цен увеличить в 2 раза то длительность твоего запроса , думаю, увеличится как минимум в 3 раза.
И вот еще что . Как и в (0) нужно , на мой взгляд, отсечь период до "Даты начала" сделав вначале соединение со срезом последних регистра цен.
14. Ish_2 1104 03.11.10 08:18 Сейчас в теме
(12) +13 Ведь твой вложенный запрос в (8) выполнится столько раз - сколько записей в регистре ЦеныНоменклатуры (если продажи анализируются для всей номенклатуры и без ограничения периода). Еще раз повторяю - выглядит симпатично , но нужно проверять.

С другой стороны, если бы поле выборки языка запроса 1с могло быть запросом (как во всех диалектах SQL), то :

ВЫБРАТЬ 
   Продажи.Период, 
   Продажи.Контрагент, 
   Продажи.Номенклатура, 
   Продажи.КоличествоОборот КАК Количество, 
   Продажи.СтоимостьОборот КАК Стоимость, 
   (ВЫБРАТЬ ПЕРВЫЕ 1 
               Цены.Цена 
            ИЗ 
               РегистрСведений.ЦеныНоменклатуры КАК Цены 
            ГДЕ 
               Цены.Период <= Продажи.Период 
               И Цены.Номенклатура = Продажи.Номенклатура 
               И Цены.ТипЦен = &ТипЦен 
            УПОРЯДОЧИТЬ ПО 
               Цены.Период УБЫВ) как Цена 
ИЗ 
   РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи 
Показать


В этом случае вложенный запрос выполнится столько раз сколько записей в основном запросе.
15. Ish_2 1104 03.11.10 12:38 Сейчас в теме
А вообще, пост (14) об относительности совершенства любого алгоритма.
С точки зрения специалиста 1с - приведенный в (0) алгоритм можно считать образцом.
Cпециалист же знакомый с SQL воскликнет :
"Какое извращение ! Из за ограничений языка запросов 1с ребятам приходится кувыркаться и изобретать велосипед с квадратными колесами (0)"
RozalievAndrey; +1 Ответить
16. I_G_O_R 69 03.11.10 14:39 Сейчас в теме
(12) насчет среза согласен, но в этом случае я бы делал как в статье, а то мой запрос из красивого и короткого превратится длинный и некрасивый
19. Ish_2 1104 06.11.10 05:49 Сейчас в теме
(12) Так, что , Игорь , поговорили ... и всё ?
В (8) ты привел свой альтернативный вариант запроса. Давай уж выясним до конца :
Быстрее ли он работает , чем вариант приведенный в статье (0) ?
На больших объемах данных. Что скажешь ?
20. I_G_O_R 69 06.11.10 16:45 Сейчас в теме
(19) может быть и не быстрее, зато красиво. С группировками способ все знают, а мой наверное меньше. Я не против проверить, но бызы нет под рукой, могу только на работе. Вообще идея просто сгенерировать базу, в которой будет много номенклатуры(? только сколько)и например каждый день записана цена и каждая номенклатура продавалась каждый день 1 раз. А вообще я ща в гости иду, так что сегодня некогда.
21. Ish_2 1104 06.11.10 16:47 Сейчас в теме
(20) Много не пей. Послезавтра ..проверять запрос.
22. I_G_O_R 69 14.11.10 14:42 Сейчас в теме
(21) уже заждался наверное результатов, а результаты очень прикольные. Тесты проводил на сгенерированной базе: регистры были в точности перенесены из УТ, только удалены измерения, которых нет в запросе, вообщем все свойства этих измерений(индексировать, ведущее) совпадают. В базе 10000 номенклатуры, 500 контрагентов, с начала 2010 года на каждый день для каждой номенклатуры есть запись в регистры ЦеныНоменклатуры, в регистре Продажи есть одна на запись на каждый день одной номенклатуры и случайным образом подобранным контрагентом(т.е за один день 10000 записей а кому она продалась это как повезет). Для замеров использовались запросы:

1) это запрос из статьи с исправлением ошибок и без индексов(без индексов показал лучшие результаты):
ВЫБРАТЬ
	ПродажиОбороты.Период КАК Дата,
	ПродажиОбороты.Контрагент КАК Контрагент,
	ПродажиОбороты.Номенклатура КАК Номенклатура,
	ПродажиОбороты.КоличествоОборот КАК Количество,
	ПродажиОбороты.СтоимостьОборот КАК Стоимость
ПОМЕСТИТЬ втБезЦены
ИЗ
	РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК ПродажиОбороты

;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
	втБезЦены.Дата КАК Дата,
	втБезЦены.Контрагент КАК Контрагент,
	втБезЦены.Номенклатура КАК Номенклатура,
	втБезЦены.Количество,
	втБезЦены.Стоимость,
	МАКСИМУМ(ЦеныНоменклатуры.Период) КАК Период
ПОМЕСТИТЬ втМаксПериод
ИЗ
	втБезЦены КАК втБезЦены
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ПО втБезЦены.Номенклатура = ЦеныНоменклатуры.Номенклатура
			И втБезЦены.Дата >= ЦеныНоменклатуры.Период
			И ЦеныНоменклатуры.Период <= &КонецПериода
			И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)

СГРУППИРОВАТЬ ПО
	втБезЦены.Дата,
	втБезЦены.Контрагент,
	втБезЦены.Номенклатура,
	втБезЦены.Количество,
	втБезЦены.Стоимость

;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
	втМаксПериод.Дата,
	втМаксПериод.Контрагент,
	втМаксПериод.Номенклатура,
	втМаксПериод.Количество,
	втМаксПериод.Стоимость,
	ЦеныНоменклатуры.Цена
ИЗ
	втМаксПериод КАК втМаксПериод
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ПО втМаксПериод.Номенклатура = ЦеныНоменклатуры.Номенклатура
			И втМаксПериод.Период = ЦеныНоменклатуры.Период
			И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
Показать


2) мой:
ВЫБРАТЬ
	Продажи.Период,
	Продажи.Контрагент,
	Продажи.Номенклатура,
	Продажи.КоличествоОборот КАК Количество,
	Продажи.СтоимостьОборот КАК Стоимость,
	ЦеныНоменклатуры.Цена
ИЗ
	РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК Продажи
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ПО Продажи.Номенклатура = ЦеныНоменклатуры.Номенклатура
			И (ЦеныНоменклатуры.ТипЦен = &ТипЦен)
			И (ЦеныНоменклатуры.Период В
				(ВЫБРАТЬ ПЕРВЫЕ 1
					Цены.Период
				ИЗ
					РегистрСведений.ЦеныНоменклатуры КАК Цены
				ГДЕ
					Цены.Период <= Продажи.Период
					И Цены.Номенклатура = Продажи.Номенклатура
					И Цены.ТипЦен = &ТипЦен
				УПОРЯДОЧИТЬ ПО
					Цены.Период УБЫВ))
Показать


замеры делал за январь, таким образом получилось, что истории цен не было. В файловой базе я вообще не мог дождаться результатов, поэтому результаты для серверной, 1С 82 и MS SQL Express 2008R2, тестировал на своем ноуте. sql сервер каждый перегружал, поэтому первый резльтат для холодного сервера, а второй для горячего
Вот собственно и результаты за январь:
1 запрос: 1 запуск - 90 сек, 2 запуск и последующие 27 сек
2 запрос: 1 запуск - 400 сек, 2 запуск 10 сек

и результаты за октябрь:
1 запрос: 1 запуск - 210 сек, 2 запуск и последующие 155 сек
2 запрос: 1 запуск - 400 сек, 2 запуск 10 сек

таким образом мой запрос не зависит от истории и выпоняется быстрее, но что-то уж очень долго первый раз после запуска sql сервера долго выполняется, с чем это связано даже не знаю, может ты чо-нибудь скажешь.

запрос из статьи необходимо оптимизировать, ограничить выборку цен срезом последних, я этого не делал, но думаю что результаты буду сравнимы с тестом за январь, когда истории цен не было.
grey.grouse; myoker; Bold Enough; SamMix; vasyak319; WellMaster; serge_focus; Zircool; SirYozha; +9 Ответить
23. Ish_2 1104 14.11.10 16:39 Сейчас в теме
(22) Знал, что ты ответишь !
Задал ты задачку.
Так что же лучше "в среднем" для обычной работы в УТ ?

Очень похоже , что при отработке твоего запроса при первом запуске sql-сервер создает и грузит в память ВЕСЬ индекс регистра по полю Период. Именно работа по этому индексу съедает 90% времени. При последующих запусках этого не происходит поэтому и время всего 10 сек.
НО.
Если после первого запуска произошли серьезные изменения в регистре цен (пользователи начали работу), то старый индекс в кэше не может быть использован и он должен быть пересоздан. И тогда при следующем запуске твоего отчета - снова тормоза ?
Свою первую статью помнишь ? С тех пор прогнозирую с опаской.
Так что = это всего лишь предположения.
Если они верны , то тогда я бы отдал предпочтение запросу приведенному в статье ( со всеми необходимыми исправлениями и добавлениями)


25. I_G_O_R 69 14.11.10 18:17 Сейчас в теме
(23) а как узнать точно что скл делал всё это время, план выполнения я смотрел и он не меняется
(24) а насчет индексов: с индексами где-то раза в два медленнее выполнялся запрос
26. Ish_2 1104 14.11.10 18:28 Сейчас в теме
(25) Прав я или нет - можно узнать если на горячем сервере после первого запуска твоего отчета в регистр Цены занести 1000 новых записей. И после этого запустить твой отчет .
Если время будет 400 сек - то я прав. Если 10 сек - то я не прав.
27. I_G_O_R 69 14.11.10 22:03 Сейчас в теме
(26) да оказался прав но на 50% )), занес 10000 записей в один день и время запроса составило 175 сек, а потом опять 10. Потом я переписал на временные таблицы свой запрос и добавил в запрос из топика срез последних, в итоге на холодном сервере время выполнения обоих запросов 45-50 сек, на горячем 35-40. Не пойму только почему раньше были более стабильные результаты. Много тестов не делал, той мой запрос выиграет, то из топика, вообщем буду считать что одинаково. В последних запросах теперь мне не нравится, что в регистре Цены номенклатуры куча индексов (в моей базе только по ЦеныНоменклатуры данные - 236 Мб, а индексы 730 Мб), которые почти никак не используются
28. Ish_2 1104 14.11.10 22:31 Сейчас в теме
(27) Сбил с толку. Совсем.
Смутил этими 50 %(175 сек) , малопонятны пока и (45-50),(35-40).
29. I_G_O_R 69 14.11.10 23:06 Сейчас в теме
(28)
малопонятны пока и (45-50),(35-40)

что непонятного , один раз запущу запрос выполнился за 45 сек, другой раз за 50 а третий может быть за 47. т.к. повторов делал мало написал через тире минимальное и максимальное занчение.
30. Ish_2 1104 15.11.10 00:04 Сейчас в теме
(29) Да, нет.
Малопонятен сам такой эффект . Почему так получилось ... такие диапазоны значений.
57. WellMaster 104 10.12.14 18:48 Сейчас в теме
(22) I_G_O_R,
Дополню.
Если подобная конструкция используется в Универсальном отчете (или вообще через ПостроительОтчетов), то может оказаться, что пользователь не задал "Период" как одно из измерений строк. При этом отчет будет ругаться на строчку
Цены.Период <= Продажи.Период

(не будет находить Поле "Период" таблицы "Продажи").

Решением проблемы может стать способ
Цены.Период <= Продажи.ДокументПродажи.Дата


З.Ы. Проверено на себе
58. alex_sayan 26.12.14 06:19 Сейчас в теме
(57) WellMaster,

Цены.Период <= Продажи.ДокументПродажи.Дата


слишком злобная конструкция. Задачу-то она может и позволит решить, да только в большой базе может сильно ударить по производительности...
59. WellMaster 104 26.12.14 08:32 Сейчас в теме
(58) puzakov, не спорю. Но хоть что-то.
10. Ish_2 1104 03.11.10 00:44 Сейчас в теме
(10) Проверить не могу. Навскидку :
Выглядит симпатично. Могу предположить , что работает быстрее ,чем пример в статье.
И думаю, вот почему : твой запрос не требует создания дополнительных временных индексов , а использует уже существующие индексы регистра. Насколько я понимаю, все выражения в условии соединения составлены так , что не требуют "дополнительных" усилий от оптимизатора запроса. Ну , а сам то ты сравнивал по быстродействию свой запрос и запрос из статьи ?
67. vis_tmp 32 19.02.17 14:55 Сейчас в теме
(10)(22) Спасибо, отлично работает!
17. V_V_V 03.11.10 16:15 Сейчас в теме
Народ, ну вам же не надо объяснять, что "длинный" и "некрасивый" запрос 1С 8 - это НЕ всегда неоптимально и малоэффективно... :D
18. Rabajaba 354 04.11.10 10:32 Сейчас в теме
Тоже долго думал как собрать среднесписочное количество сотрудников, добавил справочник "ПериодыУчета" с 3-мя полями: "ДатаНачала", "ДатаОкончания", "ВидПериода"(День,Месяц,Год). В результате получить по дням можно все что угодно, при этом запрос остается читабельным и компактным. Ну а для регистров накопления конечно лучше использовать параметр виртуальной таблицы "День".
24. Ish_2 1104 14.11.10 17:45 Сейчас в теме
(0) Про команду "Индексировать".
На мой взгляд явно создавать индекс при помощи этой команды нужно только при многократном обращении к таблице . При однократном обращении этого делать не нужно - оптимизатор запроса сам создаст нужный индекс в нужном ему виде.
Казалось бы это замечание малосущественно. Но.
Мало того , что явное создание индекса командой "Индексировать" при однократном обащении не дает выигрыша -
оно еще и даёт очень существенный проигрыш.
На этот эффект мы натолкнулись с Alex-is при тестировании Примера 3 в его "Заметочках...".
sergos3331; +1 Ответить
31. vitaliyua 17.01.11 21:18 Сейчас в теме
Подскажите пожалуйста. Сделал по вашему примеру отчет в наборе данных. После добавления цены в ресурсы и выбранные поля, в отчете в строках цены пусто. Если убираю галочку "рассчитывать по" номенклатуре напротив цены, тогда цена в строках появляется.
33. Iaskeliainen 384 29.06.12 12:43 Сейчас в теме
Аналогичная задача на запросе.
Тут остатки на каждый день * цены номенклатуры на дату остатком,
там суммы документов в у.е. * курсы валют на день документа.

"Курсы валют на разные даты в одном запросе. Делаем свой нестандартный срез последних."
http://infostart.ru/public/140933/
34. Flashback1979SE 15.08.12 05:01 Сейчас в теме
ну ваще ниньзя

PS: тоже люблю максимально работать запросами
35. ManyakRus 483 28.12.12 14:43 Сейчас в теме
всё правильно, только не забыть:
1) в первом запросе обязательно сгруппировать данные,
в несгруппированных все цифры потом задвоятся, затроятся.
2) в третьем запросе главное не сгруппировывать или обязательно сгруппировывать по периоду
(я сам не понял почему)
3) все группировки из первого запроса должны быть и во втором, чтоб цифры не задвоились.
(а может и нет)

что не нравится:
группировать по числовым колонкам нежелательно,
это тоже самое что написать
ТЗ.Свернуть("Товар,СуммаРуб","СуммаШт") - СуммаРуб должна быть в правой части а не в левой.
36. Поручик 4670 01.11.13 20:23 Сейчас в теме
Спасибо автору, пригодилось для разработки. Почему-то с соединением средствами СКД не взлетело, а чисто на запросе получилось.
Spacer; _also; +2 Ответить
54. natarezn 01.09.14 10:35 Сейчас в теме
(36) Поручик, что делать, если дата пустая ?
39. Abbra 23 08.01.14 19:44 Сейчас в теме
Для тех, кто не понимает (пока?) вложенные запросы и соединения есть еще вариант для СКД - Вычисляемые поля.
Делаем вычисляемое поле Цена и в Выражение ставим - Ценообразование.ПолучитьЦенуНоменклатуры(Субконто1, Субконто2.ТипЦенРозничнойТорговли, Период, Константы.ВалютаРегламентированногоУчета.Получить(), 1, 1)
Это частный пример для бухгалтерии 2.0.
И очень надеемся на кеширование. )
PowerBoy; +1 Ответить
40. Gureev 18.02.14 13:31 Сейчас в теме
Столкнулся с проблемой в СКД.

Ни в какую не хочет показывать данные на дату. Показывает только срез на текущую дату.

Как только не вертел, не пойму в чем причина.
Такое ощущение, что из источника в приемник параметр не передается.
41. Gureev 18.02.14 15:03 Сейчас в теме
Решил проблему.
Похоже, в соединении наборов данных, первую связь нужно делать по периоду, вторую по другим полям.
Так заработало... колдунство какое-то.
42. alex_sayan 07.03.14 10:13 Сейчас в теме
Во втором наборе данных нужно было передавать параметры через расширение языка запросов.


РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
            {(&Дата)},
            {(Номенклатура = &Номенклатура
                И ТипЦен = &ТипЦен)})


Иначе отработает неправильно.
48. ildarovich 7850 07.03.14 14:15 Сейчас в теме
Тогда поподробнее расскажите как тестировали, может быть запрос не оптимально написали, на каких данных тестировали, файловый или серверный вариант, схему компоновки и запрос приведите. Действительно интересно. Просто я сравнивал как-то разные варианты "нарезки" последних. Выяснил, что классический метод из двух запросов очень эффективен - там практически нет потерь времени. Поэтому не представляю, где может быть выигрыш. А то, что Вы говорите в памяти или на диске может не быть решающим фактором.
49. alex_sayan 07.03.14 16:22 Сейчас в теме
50. ЧИА 169 13.04.14 21:49 Сейчас в теме
(48) ildarovich,
Выяснил, что классический метод из двух запросов очень эффективен - там практически нет потерь времени. Поэтому не представляю, где может быть выигрыш.


если в СКД отборы, то фильтр дает ускорение
но - это не совсем корректное сравнение - запрос без отбора и СКД с отбором

если в СКД есть отборы, то в текст запроса надо их тоже добавить, программно, например "из остатки(,"+отбор+")"
и тогда сравнивать
51. ЧИА 169 13.04.14 22:11 Сейчас в теме
_also,

В том виде, что есть сейчас, если опубликованный запрос запустить на УТ 10 и т.п., неподготовленный человек сильно удивится )

Во все три выборки надо вставить характеристику
52. _also 484 15.04.14 09:32 Сейчас в теме
(51) ЧИА, насколько помню, демо-пример вообще на демо УПП писал. Да и учет по характеристикам может быть включен или не включен.
53. Al777 16.07.14 13:59 Сейчас в теме
Статья мне сильно помогла при разработке отчёта на СКД, но с более широкими возможностями. Сделал по второму варианту, но так как выводились не все товары с несуществующими ценами, то сделал связь по типу первого варианта. Чисто первый вариант работает очень долго по всей номенклатуре, поэтому от него отказался, хотя он и проще и быстрее в реализации.
55. natarezn 01.09.14 10:36 Сейчас в теме
спасибо за запросы - пригодились!
56. FlyVodolaz 02.12.14 10:05 Сейчас в теме
Запрос должен быть совсем другим, не нужно группировать лишнюю информацию и по максимум сократить подзапрос втМаксПериод

ВЫБРАТЬ
    ПродажиОбороты.Период КАК Дата,
    ПродажиОбороты.Контрагент КАК Контрагент,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    ПродажиОбороты.КоличествоОборот КАК Количество,
    ПродажиОбороты.СтоимостьОборот КАК Стоимость
ПОМЕСТИТЬ втБезЦены
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, День, ) КАК ПродажиОбороты


;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
   втБезЦены.Номенклатура,
   втБезЦены.Дата КАК Дата,
   МАКСИМУМ(ЦеныНоменклатуры.Период) КАК Период
ПОМЕСТИТЬ втМаксПериод
ИЗ
    втБезЦены КАК втБезЦены
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО втБезЦены.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И ЦеныНоменклатуры.ТипЦен = &ТипЦен
            И втБезЦены.Дата >= ЦеныНоменклатуры.Период

СГРУППИРОВАТЬ ПО
    втБезЦены.Дата,
    втБезЦены.Номенклатура
;

ВЫБРАТЬ
   втМаксПериод.Номенклатура,
   втМаксПериод.Дата КАК Дата,
   ЦеныНоменклатуры.Цена КАК Цена
ПОМЕСТИТЬ втЦеныНаДату
ИЗ
    втМаксПериодКАК втМаксПериод
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
        ПО втМаксПериод.Номенклатура = ЦеныНоменклатуры.Номенклатура
            И втМаксПериод.Период = ЦеныНоменклатуры.Период
            И ЦеныНоменклатуры.ТипЦен = &ТипЦен

ИНДЕКСИРОВАТЬ ПО
    Номенклатура,
    Дата

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
    втБезЦены.Дата,
    втБезЦены.Контрагент,
    втБезЦены.Номенклатура,
    втБезЦены.Количество,
    втБезЦены.Стоимость,
    втЦеныНаДату.Цена
ИЗ
    втБезЦены КАК втБезЦены
        ЛЕВОЕ СОЕДИНЕНИЕ втЦеныНаДату КАК втЦеныНаДату
        ПО втБезЦены.Номенклатура = втЦеныНаДату.Номенклатура
            И втБезЦены.Дата = втЦеныНаДату.Дата

АВТОУПОРЯДОЧИВАНИЕ
Показать
60. ui69 41 02.03.15 20:20 Сейчас в теме
А как вычислить стоимость Цена*Количество, если Количество в первом наборе данных, а Цена во втором?
64. Chandr73 16.02.16 12:53 Сейчас в теме
Спасибо большое, пригодилось!
twilight_dream; +1 Ответить
65. aleksdiez 4 11.05.16 14:01 Сейчас в теме
Условие по ТипуЦен надо указывать в связи пацаны ;)
twilight_dream; +1 Ответить
66. BAE1234567 16.08.16 16:01 Сейчас в теме
Оч. здорово! Спасибки за статью!
twilight_dream; +1 Ответить
68. KazanKokos 10 31.05.17 13:12 Сейчас в теме
отлично. как раз нужно
twilight_dream; +1 Ответить
69. SmArtist 98 20.06.17 08:23 Сейчас в теме
70. inf012 07.07.17 08:50 Сейчас в теме
Спасибо!
именно по вашей статье получилось
71. rick_77 09.11.17 15:07 Сейчас в теме
Добрый день!
Вопрос подобный.
Возможно ли средствами 1с вывести список материалов, которые не списаны более 30 ней?
Спасибо!
72. user693558_zdorenkomail 01.02.19 14:39 Сейчас в теме
Подскажите как в данный пример прикрутить пересчет валютной цены из регистра ЦеныНоменклатуры по курсу?
74. twilight_dream 19.05.19 11:12 Сейчас в теме
Большое спасибо! Избавили от мук творчества и сэкономили массу времени и нервов.
Ну, то что тип цен в левое соединение нужно прикручивать, надеюсь, кто хотел - догадался.
75. user1022955 13.08.19 06:39 Сейчас в теме
Автор ты молодец конечно.
Но твой пример будет работать только если у тебя в базе один-единственный вид цен.
А если видов цен несколько - то во втором запросе пакета надо наверное поставить условие по виду цен, иначе ты там много чего наловишь.
76. d4rkmesa 20.09.19 08:18 Сейчас в теме
Вот столько времени прошло, а иногда подсматриваю, когда забываю, как оно работает. Респект автору за читабельность.
GetNight; mikl79; +2 Ответить
79. GetNight 46 26.11.21 06:23 Сейчас в теме
Исчезли картинки. Статья актуальная всегда, но без картинок сильно теряет.
Оставьте свое сообщение