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

СГРУППИРОВАТЬ ПО
   Продажи.Период,
   РасчетыСКонтрагентами.Период,
   РасчетыСКонтрагентами.СуммаВзаиморасчетов,
   Продажи.Подразделение,
   Продажи.ЗаказПокупателя,
   ТоварыКПередачеСоСкладов.Период

Очень хочется, чтобы отчет был быстрым, а не вешал работу на пару часов :))
З.ы. Если не брать Товары к передаче со складов - то еще более-менее считает, 3 таблицы - просто жесть :(

Ну только не говорите, что никто не сталкивался. Я с УТ 3ю неделю работаю, мож есть какой то другой способ получения тех же данных? хотя я пошукал по регистрам, вроде только в них данные пишутся...

вот так вот без параметров и виртуальных таблиц? ловко ))

(2) Ну а как я в параметры передам вычисляемое поле? Получается, заказ покупателя был месяц назад, а оплатили только сейчас. Вот мне и надо увидеть этот заказ, как прибыль сейчас, а не месяц назад. Если знаешь - подскажи, будь другом. А про ВТ... куда ее тут?

(3) а если оплатили, но не полностью или оплачивали разными периодами?

(4) Вот! Если заказ на 2000р, а оплата 1500, то в отчет - 1500. Если он завтра "довнес" 500р. - то это уже завтрашняя прибыль

(5) так у тебя жеж нет этого, просто будут две суммы

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

(7) видимо ты не договариваешь, мой уровень телепатии слишком слаб

ЗаказПокупателя|Период|Сумма
где период = максимальный период из обоих регистров, а сумма = минимальная сумма из этих регистров

(8)теперь договорил, вроде)))

(9) как это с запросом коррелирует?

Через вычисляемое поле "сумма" выражение:Выбор когда Стоимость>СуммаВзаиморасчетов тогда СТоимость иначе СуммаВзаиморасчетов конец и "Дата" выражение:Выбор когда период>Период1 тогда Период иначе Период1 конец. Группировка по ЗаказПокупателя. и все.

В сумме не >, а <

(11) Мож как по другому сделать? Мож не прав я и не туда копаю?

(0) торговля идет в разрезе заказов?

(15) Да.

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

(17) обычно показывают так: заказ, сумма заказа, сумма отгрузки, сумма оплаты

Периодами выбираются продажи из рн.продажи по заказам и через объединить подвязывают взаиморасчеты в разрезе заказа

(17) Тут не в кассовом методе дело. Магазины вполне устраивает существующая схема. Открыли интернет-магазин. Магазин продает товар с точек. Деньги могут внести и в интернет магазине, а вот отгрузка пройдет через день, например, надо чтоб и продажа была не в момент получения денег, а в момент отгрузки.
(18) суммы, это ладно, как мне даты получить не перелапачивая все регистры сведений с момента появления конторы?

(19) Видишь тут как - нет явного периода. В продажи пишутся данные после проведения "реализации товаров и услуг". но это не всегда нужная дата

(20) тогда вопрос, деньги подвязали к заказу, что мешает в день отгрузки делать РТиУ

(21) тогда доп свойство тебе в помощь, свойство у заказа "дата отгрузки"

(21) не понятно, почему реализация это не всегда нужная дата

(22) ЕЕ делают в момент заказа. Тут схема такая в конторе, что реализация у них идет как резервирование товара. Типа ИМ продал, вы не трогайте.
(23) У меня еще и дата доставки есть. Предлагаешь период задавать через Дату отгрузки? а вдруг ее отгрузили, а деньги получили позже. как тогда?

(21) по опыту если клиент заплатил, это еще ничего не значит. Например: при выдачи заказа товар плохого качества.

(25) есть вариант ордерной схемы
а может стоит РТиУ по факту оформлять, а пока резервировать?

(26) вот тоже проблема. есть же еще всякие возвраты. НАпример, продали, деньги получили - вот она прибыль, а потом товар вернули, деньги вернули, вот они - расходы. Тогда в отчет должен минус попадать

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

(27) Да я тут 3ю неделю - еще толком не знаю что к чему. Предыдущий прог, якобы, говорил им, чтоб РТиУ оформляли, а не раелизацию. КОнфа писанная-переписанная, тот прог уволился, щас им структуру менять вроде как не вариант, надо приглядеться

(27),(29) а вот на том что есть есть возможность какая то написать этот отчет? им прибыль считать надо, они как считать не знают

(28) в ут 10.3 прибыль идет только при отгрузке.

(31) они - это кто? Может тебе лучше узнать истинного заказчика этих отчетов.

(32) ну в смысле поступление денежн средств

(33) интернет магазин заказчик. и их я знаю :))

(31) ибо когда говорят, про прибыль при получении денег должно настораживать

(35) я про человека

(34) тода отчет должен быть из двух колонок сумма отгрузки сумма оплаты. Далее пользователь может расшифровать до дня если надо

(37) Че ее знать то, девонька лет 27ми. В БУ не шарит, отчитываться надо... да все как всегда, короче... Сменил контору, а суть осталась та же

Останется только вопрос. В отчете есть период . Это период отгрузки или период оплаты или период заказа?

(38)Сумму оплаты я беру из Рассчеты с контрагентами, Сумма отгрузки, это реализация, так? Это я уже сделал.
(40) Суть то как раз в том, что период в отчете - это максимум из этих 3х периодов

(39) перед налоговой? Скорее всего это мелкий им, наверное учет идет по Усн, следовательно кассовый метод. Тогда пусть смотрит отчет по взаиморасчетам

(42) перед директором всей движухи)) Как отчет называется? ща гляну, в УТ еще пока не шарю толком

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

(41) тебе кто это сказал? Если это для отчетности в бух то там вариант по дате отгрузки или по оплате. В упр учете не любят кассовый метод, поэтому по отгрузке. Микс из максимум это что -то очень странное. Но! Если очень хочется, то предварительно делай расчет этой даты в разрезе заказов, потом вытягивай деньги и проджи через отбор по зааказам

(44) бабло пусть смотрит через ддс , в приходниках будет указывать статью ддс (например: оплата от покупателя)

(46) в возвратах будет статья возврат покупателю.

вижу тока отчет по взаиморасчетам с комиссионерами и комитентами...
(45) Вот смотри, как мне рассчитать эту дату в разрезе заказов. Конкретный пример: Заказ покупателя на 20000 от 16.10 РТиУ на 13000 от 17.10. ПКО на 13000 от 18.10. В отчет должно лечь: заказпокупателя номер блаблабла, сумма - 13000, дата - 18.10. А в отборе, например, стоит период с 18 по 19.получается, заказ сюда должен выпасть, но в самом заказе это 18.10 нигде не фигурирует

вот как тут быть?

(46) ддс, я так понимаю, это по кассам, трабл в том, что у ИМ нет кассы. Вернее есть, но она общая с обычным магазином.

ЩАс понял, что моя схема из (0) на самом деле не работает. Если есть только заказ покупателя и РТиУ, заказ тоже попадает в отчет, ибо заказ покупателя тоже делает движения по расчетам с контрагентами, т.е. условие, что должен быть документ поступления денежных средств уже не выполняется...

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

(51) что-то мешает использовать Рг Взаиморасчёты ?

(52) вот нифига - деньги могут отдать сегодня (ПКО), а отгрузка будет через неделю(ну типа заказал с предоплатой и сидишь ждешь). Вот пока не отгрузили - денег, как будто, тоже нет

(53) То, что платежное поручение входящее по нему движений не делает

+(55) т.е. все хорошо, пока ничего не купило Юр лицо

(55) брехня

(57) ТОчно, вру. Ок, схема (0) работает, но работает так же долго. Че делать то?

(58)[Че делать то]
учиться программировать

(59) Вот ты, конечно, молодец. Я же не спрашиваю "как сделать, чтоб работало". Я спрашиваю, "как выбрать данные так, чтобы не перебирать все записи". И мне пока не ответили, хотя умных мыслей, конечно, накидали, сэнкс. Но в итоге, я щас там же где и был. вот ты, shuhard, если умеешь программировать, скажи мне, какие параметры передать запросу?

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

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

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

Хотя, (61) - это мысль. Попробую реализовать. Но данные то уже сейчас получить надо, а не через месяц,когда данные будут вводиться коректно..

(62) никто не мешает сделать так, чтобы только при работе с интернет магазином была такая система.

(63) также после того, как введешь эту систему, можно провести документы по инетмагазину, скажем, за прошедшие два месяца и будут тебе цифры на сегодня.

(64) ну, то есть никак не получить их через опу то? пичалька

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

(65) в этом смысла просто нет. Надо формировать в нужное время регистр продажи и всё. Тем более в нем уже есть нужное для вас измерение, называется "заказПокупателя" сделайте туда возможным заносить документ реализации и делов.

(67)Т.е. я тебя правильно понял: если организация инетмаг, то движения по продажам делать только если реализация была со склада или есть расходный ордер на товары.Если реализация по Ордеру и нет самого ордера - движения не делать? А в остальном - просто внутреннее соединение с регистром Взаиморасччеты с контрагентами. Так?

(68) Да. Только зачем для отчета нужен регистр Взаиморасчеты с контрагентами.

(69) НУ а как мне отслеживать сумму оплаты от покупателя (ПКО,  платежное поручение входящее и оплата пластиквой картой)?

+(70) они ж в "продажах" вообще движений не делают

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

(71) да, в стандартной логике программы не делают. В твоей делают.

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

(73) Это конечно не самое красивое решение. Но имеет право на жизнь.

Логика то проста, вариантов может быть несколько:
1. Отгрузили без предоплаты (не делаем запись в регистр)
2. Отгрузили и сперва была предоплата (делаем запись в регистр с нужными данными и меньшей суммой из этих двух документов)
3. Поступили деньги и не было отгрузки (не делаем запись в регистр)
4. Поступили деньги и была отгрузка (делаем запись в регистр с нужными данными и меньшей суммой из этих двух документов)

И потом СКД по этому регистру и счастье )

mih_io, Вот прям большое тебе Спасибо. Щас хоть мысли по местам встали. Буду на неделе реализовывать, посмотрю, что получится.

(75) надо только не забывать восстанавливать последовательность, чтобы система железно работала. И уточнить варианты у юзеров, когда оплатили по документу больше чем было отгружено, что тогда делать? В этом случае при оплате надо проверять, сколько уже было оплачено, вообщем то и всё.

Хотя я не знаю, как у вас планируется, при оплате указывать конкретно за какую реализацию оплатили или по очереди все реализации закрывать...