|
Подскажите по простейшему (условному) запросу | ☑ | ||
---|---|---|---|---|
0
PiotrLoginov
25.12.17
✎
16:27
|
Всем привет. Очередная темка на форуме по принципам построения запросов. Сам люблю заморочиться построением сложных запросов, но тут что-то спасовал:
Есть таблица ПЕРИОД РЕГИСТРАТОР КОЛВО 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 Т.е. вычесть из продаж количество возвращенного, даже если количество у покупателя уйдет в минус, учитывая, что каждый возврат может вычитать только из продажи, появившейся раньше, чем этот возврат. Сделать без использования запросов не предлагать. |
|||
1
PiotrLoginov
25.12.17
✎
16:28
|
Волшебник, за шапочку спасибо
|
|||
2
PiotrLoginov
25.12.17
✎
16:29
|
У меня есть вариант, но он кажется мне неоправданно сложным. Попробую сформулировать и привести. Но мб есть варианты лаконичнее...
|
|||
3
Джинн
25.12.17
✎
16:31
|
Объедините таблицы с группировкой сводной по необходимым реквизитам. Или соедините две таблицы и просуммируйте ресурсы.
Только в случае с регистратором полная хрень получится в итоге. |
|||
4
Михаил Козлов
25.12.17
✎
16:31
|
Если это регистр накопления "Продажи", то в нем обычно бывает измерение "ДокументПродажи". Тогда обороты в разрезе документов продажи дадут Вам нужное количество. А период возьмете из реквизита документа продажи.
|
|||
5
PiotrLoginov
25.12.17
✎
16:32
|
(3) мне бы, чтобы "нехрень" получилась
(4) нет, это не регистр с измерением по документу продажи, так что это не рассматриваем |
|||
6
Джинн
25.12.17
✎
16:34
|
(5) Чтобы "нехрень" получилась, в самой логике задачи "нехрень" должна быть. А у Вас хрень.
|
|||
7
PiotrLoginov
25.12.17
✎
16:38
|
(6) да не... обычная "боевая" задача. Есть некая ситуация, которую я не буду описывать, поскольку мне сразу посоветуют не страдать ерундой, а скорректировать учет. Но занимается учетом другой спец, а моя задача - только помочь ему на лету вычислять остатки проданного по каждому документу продажи без использования партионных регистров. Лезть так глубоко в его кухню я не стану.
|
|||
8
piter3
25.12.17
✎
16:39
|
(7) удачи
|
|||
9
Джинн
25.12.17
✎
16:40
|
(7) Тогда в возвратах должна быть ссылка на документ продажи. Связь по регистратору не прокатит - они разные будут.
|
|||
10
PiotrLoginov
25.12.17
✎
16:40
|
(8) не-не-не, не надо меня бросать. Абстрагируемся от задачи. И не такое запросом вычисляли. Есть решение. Сейчас я его параллельно нашему прекрасному общению набрасываю. Но может быть кто-то даст более красивое...
|
|||
11
DexterMorgan
25.12.17
✎
16:40
|
как связано продажа 1 и возврат 1? по номеру что ли?
|
|||
12
piter3
25.12.17
✎
16:41
|
(10) Как не связанные доки???
|
|||
13
PiotrLoginov
25.12.17
✎
16:41
|
(9) именно! Но люди как-то возвращали без указания документа продажи. Не буду кидать камнями в конфу. А то холивар накликаю
|
|||
14
piter3
25.12.17
✎
16:41
|
А при перепроведении,что будет?
|
|||
15
DexterMorgan
25.12.17
✎
16:42
|
почему продажа 3 была 5, а стала 4?
|
|||
16
PiotrLoginov
25.12.17
✎
16:42
|
(11) Регистраторы никак не связаны. Пусть они будут в условии задачи абстрактным полем.
|
|||
17
DexterMorgan
25.12.17
✎
16:43
|
(16) Мля мы тут нейронные сети что ли? как ты получил результат, что за алгоритм?
|
|||
18
PiotrLoginov
25.12.17
✎
16:43
|
(15) ну как же. Возврат2 (8 штук) вычел 7 из Продажа2 и 1 из Продажа3, т.е. вычел все, что мог из тех продаж, которые были до него, и из которых есть чего вычитать
|
|||
19
PiotrLoginov
25.12.17
✎
16:45
|
(17) вот появляется Возврат1 . Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится.
вот появляется Возврат2 .Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится. |
|||
20
DexterMorgan
25.12.17
✎
16:46
|
(18) меняй архитектуру системы, это лажа, то, что ты пытаешься сделать запросом
|
|||
21
piter3
25.12.17
✎
16:46
|
(18) А если будет сторно и еще возврат как твой алгоритм будет работать
|
|||
22
PiotrLoginov
25.12.17
✎
16:48
|
(20) см. (7)
(21) сторно какой операции? не стоит заморачиваться принципами ведения учета. представьте, что вместо Продажа1 написано Измерение1 |
|||
23
DexterMorgan
25.12.17
✎
16:48
|
(21) + задним числом исправят документ
|
|||
24
DexterMorgan
25.12.17
✎
16:48
|
(22) см (20)
|
|||
25
PiotrLoginov
25.12.17
✎
16:49
|
Нет, лучше "ПолеСобытияУвеличенияОстатка1"
|
|||
26
memogolik
25.12.17
✎
16:49
|
(13) а как понять что Продаже1 соответствует именно Возврат1?
|
|||
27
DexterMorgan
25.12.17
✎
16:50
|
(22) не ну если ты извращенец, на покури http://catalog.mista.ru/public/266377/
|
|||
28
PiotrLoginov
25.12.17
✎
16:50
|
(26) задача - вычесть возвращаемое из переданного покупателю. Показать юзеру, из какой продажи количество какого возврата вычитал запрос - такой задачи не стоит.
|
|||
29
memogolik
25.12.17
✎
16:51
|
Т.е измерения только Клиент и дата?
|
|||
30
PiotrLoginov
25.12.17
✎
16:52
|
(27) там получаются готовые остатки из соответствующего регистра партионного учета. Я же написал, что в реалиях задачи партии типа не ведутся
|
|||
31
Джинн
25.12.17
✎
16:52
|
(19) В нет курсоров, построчно Вы не обработаете запрос. Только извращением с массой временных таблиц, "откусывая" по условиям нужные куски в разные таблицы, а потом объединяя результат. Но тут крыша уедет...
|
|||
32
PiotrLoginov
25.12.17
✎
16:52
|
(29) дату в исходных таблицах вижу. Клиент - не вижу.
|
|||
33
DexterMorgan
25.12.17
✎
16:53
|
(30) Мля это такой же принцип, что тебе надо, лол.
|
|||
34
DexterMorgan
25.12.17
✎
16:54
|
(30) в твоей случае партия - это документ продажи, который "закрывают" возвраты "чтобы хватило"
|
|||
35
PiotrLoginov
25.12.17
✎
16:54
|
(31) принято. но щас все-таки уйду в размышления на полчасика
(33) мне это надо. но этого нет в условиях задачи. В условиях задачи регистр партионного учета отсутствует. Все. Вернусь через полчаса. |
|||
36
DexterMorgan
25.12.17
✎
16:54
|
(31) Согласен Чистов, тот еще извращенец
|
|||
37
DexterMorgan
25.12.17
✎
16:55
|
(35) ты че издеваешься
|
|||
38
PiotrLoginov
25.12.17
✎
17:08
|
(37) ни в коем случае. в итоге принято решение обрабатывать каждый возврат неким кодом. Можете кидать тапками.
|
|||
39
DexterMorgan
25.12.17
✎
17:32
|
(38) Мне конечно все-равно на ваш овонокод и ваши "подходы" к решению задач, но еще раз для особенных: "партионный" регистр в твоем случае, регистр из (0), партия - документ продажи. в (27) чувак сделал все запросом
|
|||
40
Джинн
25.12.17
✎
17:42
|
(36) Куда деваться, если нет курсоров... Приходится извращаться.
|
|||
41
PiotrLoginov
25.12.17
✎
17:49
|
(39) я пока никакого кода не приводил. за что такие поклепы про "овнокод"? В (27) многоуважаемый "чувак" гипотетическим регистратором списал некоторые партии по ФИФО. Но там в условии нет задачи сделать это для нескольких регистраторов. Ведь когда исчерпано количество из одного регистратора, в моей задаче надо приниматься за следующий.
Я бы вообще не лез делать такое запросом, если бы уже не имел многочисленный опыт работы с остатками запросом по ФИФО. |
|||
42
PiotrLoginov
25.12.17
✎
17:49
|
(40) "курсоры"... это что имеется ввиду?
|
|||
43
Сияющий в темноте
25.12.17
✎
18:03
|
(42) Курсоры - это текущая выборка в запросе.
В "числом" SQL можно написать хранимую процедуру, которая будет не только обрабатывать каждую стоку запроса, но и будет иметь возможность ссылаться на эту строку. |
|||
44
Джинн
25.12.17
✎
18:08
|
(41) Там все аналогично :) Замените его "партия" или "товар" на Ваш "регистратор". Главное принцип.
|
|||
45
PiotrLoginov
25.12.17
✎
18:51
|
(43) понял, спс, буду знать... теперь что-то такое всплывает в мозгу. Видимо, читал когда-то, но не задержалось в голове.
(44) ну так а если не все количество в регистраторе потратилось на имеющиеся партии, надо еще и оставить что-то... не, решение частичное. базовое. |
|||
46
Сияющий в темноте
25.12.17
✎
19:22
|
Таблицы легко можно свести в таблицу продаж и возвратов, когда получаем:
Дата ВсеПродажиНаЭтуДату ВсеВозвратыНаЭтуДатуИДоСледующейДатыПродажи |
|||
47
Сияющий в темноте
25.12.17
✎
19:24
|
Тут, если возвраты превышают продажи, то "они отбрасывают тень назад по временной оси" - и вот этот момент очень тяжело вычислить запросом.
|
|||
48
Злопчинский
25.12.17
✎
19:56
|
Практически один в один задача Ильдаровича на ИС - есть оплаты - их надо распределить по документам
|
|||
49
PiotrLoginov
25.12.17
✎
20:51
|
(48) там автор исходит из принципа, что есть момент X, до которого все документы оплачены, а после которого - нет. Посмотрел бы я на него, если бы выяснилось, что некий свежий документ оплаты оформлен таким образом, что оплачивает именно документ из массива после X.
|
|||
50
PiotrLoginov
25.12.17
✎
20:51
|
+(49) но за ссылку спасибо. дала пищу для размышлений
|
|||
51
Сияющий в темноте
25.12.17
✎
21:18
|
оплаты еще и по суммам ложаться,то есть,если заплатили 1000,то если среди неоплаченных документов есть документ с суммой 1000,то оплатили именно его.
|
|||
52
PiotrLoginov
25.12.17
✎
21:43
|
(51) точно.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |