Очень нужна помощь в написании запроса. Суть такова, в УТ 11 в справочнике Номенклатура заведен доп реквизит числовой. На дату формирования отчета отбираются номенклатурные позиции на остатке и рассчитывается некая дата отсчета, как дата отчета минус этот числовой доп. реквизит. С этим проблем нет, а вот дальше необходимо отобрать начальные остатки на полученную дату отсчета (получается у каждой номенклатурной позиции своя), продажи, списания и перемещения за период с даты отсчета по дату отчета. То есть полученную дату отсчета и номенклатуру нужно использовать дальше в качестве параметров. Можно конечно перебирать в цикле полученный результат первого запроса и по каждой номенклатурной позиции отдельным запросом получать начальный остаток, продажи, списания и перемещения. Но хотелось бы обойтись одним запросом...Помогите реализовать, плиз

Если я правильно понял тчо ты хочтешь, то это сделано в ведомости товаров на складах

(1) ведомомсть товаров на складах это начальное сальдо, оборот, конечное сальдо на один и тот же период по всем номенклатурным позициям, у меня у каждой номенклатурной позиции свой период получается, точнее дата конечная у всех одинаковая - это дата отчета, а вот начальная у каждой позиции своя

(2) Не моё дело конечно, но зачем???

(3) Числовой показатель в номенклатуре это норма оборачиваемости дней товарной позиции, из начального остатка вычитаются продажи, списания и перемещения, тоже по определенному условию (складам), затем все это умножается на цену и на определенный коэффициент, получаем штрафные значения для менеджеров...Алгоритм не мой, так хочет руководство...штрафовать за заказываемый менеджерами и не проданный товар

используй тета-соединение.

(5) это внутреннее соединение? что с чем соединять? у меня в голове только один алгоритм запроса: первым пакетом получаю первоначальные данные: остатки на дату отчета, номенклатуру соответственно, дату отсчета, исходя из нормы оборачиваемости, вторым пакетом начальные остатки из ТоварыНаСкладахОстатки...и соответственно дата начальных остатков это дата отсчета предыдущего пакета...как ее туда передать? ну и далее пакет продажи, пакет перемещения, пакет списания...

конечно зациклена на одном решении...видимо в том и проблема(((

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

(8) что значит на каждую? на каждую дату в ЗАДАННОМ периоде, который заранее известен...в том то и дело, что мне не нужно на каждую дату, и период-то свой у каждой позиции, изначально я знаю только конечную дату, это дата отчета(

(8) +1
сегодня только писал отчет, еле поиском нашел ))

(10) умными мыслями и воплощением поделитесь?

(9) Надо не думать, а просто сделать: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=Срез%20последних%20на%20каждую%20дату%20в%20СКД

(11) главное читай вдумчиво и не забывай снимать автозаполнение, я на нем и промаялся час

(13) И с автозаполнением вроде работает

(14) если параметр период - то могут быть глюки

+15 при использовании в ВТ

(12) я умею пользоваться поиском...в том то и дело, что везде идет регистр сведений в примере, а мне надо накоплений, как я там по периоду соединение сделаю

может я непонятно написала, не знаю...но мне не нужны остатки на каждую дату заданного периода по всем номенклатурным позициям...

у меня у каждой номенклатурной позиции своя дата получения остатков, она одна

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

(18) (19) Так в (12) же то что нужно, только в примере с инфостарта цена а у тебя будут отстатки.
(17) У виртуальных таблиц регистров накоплений тоже есть НачалоПериода и КонецПериода. НачалоПериода ты можешь вычислить прямо в запросе а не передавать параметром

(21) да, я все и вычисляю, я не понимаю как присвоить НачалуПериода вычисленную дату...
(20)передаешь эту дату (через условие связи наборов данных) - да со стороны первого завпроса это вычисленная дата, а со стороны второго запроса, чему я ее приравняю? я вот этого не могу понять...нет у меня в регистре по остаткам поля период...или я не туда смотрю

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

(23) вы мне про СКД???? у меня обработка, часть данных берется из другой базы, я не понимаю как в этом случае СКД можно использовать, мне просто запрос нужен(((

есть дата перехода с одной программы на другую, соответственно часть недостающих данных в этой обработке берет по сом-соединению из другой базы...

(22) " со стороны второго запроса, чему я ее приравняю? я вот этого не могу понять...нет у меня в регистре по остаткам поля период" // Во втором наборе задаешь параметр виртуальной таблицы "НачалоПериода", обозвав произвольным именем, например, &ДатаСрезаНачалаПериода, а в связи наборов указываешь это вот поле с этим вот произвольным именем. То же самое, что и поле "Дата" на этой картинке: http://1cskd.ru/wp-content/uploads/2010/10/4.png

(24) Так в статье есть пример и для запроса

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

(26) мне не СКД(((
(28) да вот именно, были бы все данные в одной базе, было бы проще...

(29) Чем СКД не устраивает? Открой для себя вывод не в табличный документ, а в коллекцию

(29) В статье на которую ссылается (26) есть пример и для одного запроса с вложенными запросами.
Если данные в разных базах почему бы их не синхронизировать?

(0) а в чем проблема!? строишь таблицу начальных остатков на 10 лет(примерно) в запросе, а уж приход и расход посчитать можно!!! если не можешь за вознаграждение напишу))

(31) что значит синхронизировать? вели учет в одной базе, перенесли остатки, стали вести в другой...

тут есть дата перехода, третья дата еще есть между датой отсчета и датой отчета

(32) во первых на 10 то лет не надо, там максимальный строк оборачиваемости 150 дней...а во вторых суть не просто в начальных остатках

(33) (35) Проблема в том что переход состоялся менее 150 дней назад и в новой базе не вся информация об оборотах?
Почему в этом случае не ввести в новой базе остатки на дату перехода минус 150 дней и перенести документы движения за эти 150 дней?

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

(36) потомучто ту базу загадили напрочь, она не обновлена три года, косяки лезут со всех сторон...я боюсь перетащить вместе с такими остатками кучу всякой бяки не нужной

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

(32) только если обработку целиком, тогда за вознаграждение

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

А вообще прикольно - это, видимо, тот случай, когда запрос в цикле будет намного быстрее, чем запрос без цикла, так как иначе придётся сделать запрос к виртуальной таблице по максимальной длине и отбросить из него то, что не попало в "след" для текущего товара.

Оборот в одной базе не может быть после переноса в другую?
Тогда просто сумма за 150 дней по двум базам сразу.

(41) да, три года не обновляли и семеро программистов гадили...

(41) так и делаю((( хотелось как-то производительнее и изящнее...