Имя: Пароль:
1C
1С v8
Подскажите по простейшему (условному) запросу
,
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) точно.