Всем привет. Очередная темка на форуме по принципам построения запросов. Сам люблю заморочиться построением сложных запросов, но тут что-то спасовал:

Есть таблица

ПЕРИОД          РЕГИСТРАТОР   КОЛВО
01.10.2017    Продажа1    5
15.10.2017    Продажа2    7
20.10.2017    Продажа3    5


и есть таблица

ПЕРИОД         РЕГИСТРАТОР    КОЛВО
02.10.2017    Возврат1    -10
21.10.2017    Возврат2     -8



Необходимо получить запросом таблицу:

ПЕРИОД         РЕГИСТРАТОР    КОЛВО
01.10.2017    Продажа1    -5
15.10.2017    Продажа2    0
20.10.2017    Продажа3    4



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

Сделать без использования запросов не предлагать.

Волшебник, за шапочку спасибо

У меня есть вариант, но он кажется мне неоправданно сложным. Попробую сформулировать и привести. Но мб есть варианты лаконичнее...

Объедините таблицы с группировкой сводной по необходимым реквизитам. Или соедините две таблицы и просуммируйте ресурсы.

Только в случае с регистратором полная хрень получится в итоге.

Если это регистр накопления "Продажи", то в нем обычно бывает измерение "ДокументПродажи". Тогда обороты в разрезе документов продажи дадут Вам нужное количество. А период возьмете из реквизита документа продажи.

(3) мне бы, чтобы "нехрень" получилась
(4) нет, это не регистр с измерением по документу продажи, так что это не рассматриваем

(5) Чтобы "нехрень" получилась, в самой логике задачи "нехрень" должна быть. А у Вас хрень.

(6) да не... обычная "боевая" задача. Есть некая ситуация, которую я не буду описывать, поскольку мне сразу посоветуют не страдать ерундой, а скорректировать учет. Но занимается учетом другой спец, а моя задача - только помочь ему на лету вычислять остатки проданного по каждому документу продажи без использования партионных регистров. Лезть так глубоко в его кухню я не стану.

(7) удачи

(7) Тогда в возвратах должна быть ссылка на документ продажи. Связь по регистратору не прокатит - они разные будут.

(8) не-не-не, не надо меня бросать. Абстрагируемся от задачи. И не такое запросом вычисляли. Есть решение. Сейчас я его параллельно нашему прекрасному общению набрасываю. Но может быть кто-то даст более красивое...

как связано продажа 1 и возврат 1? по номеру что ли?

(10) Как не связанные доки???

(9) именно!  Но люди как-то возвращали без указания документа продажи. Не буду кидать камнями в конфу. А то холивар накликаю

А при перепроведении,что будет?

почему продажа 3 была 5, а стала 4?

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

(16) Мля мы тут нейронные сети что ли? как ты получил результат, что за  алгоритм?

(15) ну как же.  Возврат2 (8 штук) вычел 7 из Продажа2 и 1 из Продажа3, т.е. вычел все, что мог из тех продаж, которые были до него, и из которых есть чего вычитать

(17)  вот  появляется Возврат1 .  Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится.


вот  появляется Возврат2 .Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится.

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

(18) А если будет сторно и еще возврат как твой алгоритм будет работать

(20) см. (7)


(21) сторно какой операции? не стоит заморачиваться принципами ведения учета.  представьте, что вместо Продажа1  написано Измерение1

(21) + задним числом исправят документ

(22) см (20)

Нет,  лучше "ПолеСобытияУвеличенияОстатка1"

(13) а как понять что Продаже1 соответствует именно Возврат1?

(22) не ну если ты извращенец, на покури http://catalog.mista.ru/public/266377/

(26) задача - вычесть возвращаемое из переданного покупателю. Показать юзеру, из какой продажи количество какого возврата вычитал запрос - такой задачи не стоит.

Т.е измерения только Клиент и дата?

(27) там получаются готовые остатки из соответствующего регистра партионного учета. Я же написал, что в реалиях задачи партии типа не ведутся

(19) В нет курсоров, построчно Вы не обработаете запрос. Только извращением с массой временных таблиц, "откусывая" по условиям нужные куски в разные таблицы, а потом объединяя результат. Но тут крыша уедет...

(29) дату в исходных таблицах вижу.  Клиент  - не вижу.

(30) Мля это такой же принцип, что тебе надо, лол.

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

(31)  принято.  но щас все-таки уйду в размышления на полчасика


(33) мне это надо. но этого  нет в условиях задачи.  В условиях задачи регистр партионного учета отсутствует.  Все.  Вернусь через полчаса.

(31) Согласен Чистов, тот еще извращенец

(35) ты че издеваешься

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

(38) Мне конечно все-равно на ваш овонокод и ваши "подходы" к решению задач, но еще раз для особенных: "партионный" регистр в твоем случае, регистр из (0), партия - документ продажи. в (27) чувак сделал все запросом

(36) Куда деваться, если нет курсоров... Приходится извращаться.

(39) я пока никакого кода не приводил. за что такие поклепы про "овнокод"? В (27) многоуважаемый "чувак" гипотетическим регистратором списал некоторые партии по ФИФО. Но там в условии нет задачи сделать это для нескольких регистраторов. Ведь когда исчерпано количество из одного регистратора, в моей задаче надо приниматься за следующий.

Я бы вообще не лез делать такое запросом, если бы уже не имел многочисленный опыт работы с остатками запросом по ФИФО.

(40) "курсоры"... это что имеется ввиду?

(42) Курсоры - это текущая выборка в запросе.
В "числом" SQL можно написать хранимую процедуру, которая будет не только обрабатывать каждую стоку запроса, но и будет иметь возможность ссылаться на эту строку.

(41) Там все аналогично :) Замените его "партия" или "товар" на Ваш "регистратор". Главное принцип.

(43) понял, спс, буду знать...  теперь что-то такое всплывает в мозгу.  Видимо, читал когда-то, но не задержалось в голове.

(44) ну так а если не все количество в регистраторе потратилось на имеющиеся партии, надо еще и оставить что-то... не, решение частичное. базовое.

Таблицы легко можно свести в таблицу продаж и возвратов, когда получаем:
Дата ВсеПродажиНаЭтуДату ВсеВозвратыНаЭтуДатуИДоСледующейДатыПродажи

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

Практически один в один задача Ильдаровича на ИС - есть оплаты - их надо распределить по документам

(48) там автор исходит из принципа, что есть момент X, до которого все документы оплачены, а после которого - нет.  Посмотрел бы я на него, если бы выяснилось, что некий свежий документ оплаты оформлен таким образом, что оплачивает именно документ из массива после X.

+(49) но за ссылку спасибо.  дала пищу для размышлений

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

(51) точно.