Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Подскажите по простейшему (условному) запросу

Подскажите по простейшему (условному) запросу
Я
   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



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

Сделать без использования запросов не предлагать.
 
 
   PiotrLoginov
 
1 - 25.12.17 - 16:28
Волшебник, за шапочку спасибо
   PiotrLoginov
 
2 - 25.12.17 - 16:29
У меня есть вариант, но он кажется мне неоправданно сложным. Попробую сформулировать и привести. Но мб есть варианты лаконичнее...
   Джинн
 
3 - 25.12.17 - 16:31
Объедините таблицы с группировкой сводной по необходимым реквизитам. Или соедините две таблицы и просуммируйте ресурсы.

Только в случае с регистратором полная хрень получится в итоге.
   Михаил Козлов
 
4 - 25.12.17 - 16:31
Если это регистр накопления "Продажи", то в нем обычно бывает измерение "ДокументПродажи". Тогда обороты в разрезе документов продажи дадут Вам нужное количество. А период возьмете из реквизита документа продажи.
   PiotrLoginov
 
5 - 25.12.17 - 16:32
(3) мне бы, чтобы "нехрень" получилась
(4) нет, это не регистр с измерением по документу продажи, так что это не рассматриваем
   Джинн
 
6 - 25.12.17 - 16:34
(5) Чтобы "нехрень" получилась, в самой логике задачи "нехрень" должна быть. А у Вас хрень.
   PiotrLoginov
 
7 - 25.12.17 - 16:38
(6) да не... обычная "боевая" задача. Есть некая ситуация, которую я не буду описывать, поскольку мне сразу посоветуют не страдать ерундой, а скорректировать учет. Но занимается учетом другой спец, а моя задача - только помочь ему на лету вычислять остатки проданного по каждому документу продажи без использования партионных регистров. Лезть так глубоко в его кухню я не стану.
   piter3
 
8 - 25.12.17 - 16:39
(7) удачи
   Джинн
 
9 - 25.12.17 - 16:40
(7) Тогда в возвратах должна быть ссылка на документ продажи. Связь по регистратору не прокатит - они разные будут.
   PiotrLoginov
 
10 - 25.12.17 - 16:40
(8) не-не-не, не надо меня бросать. Абстрагируемся от задачи. И не такое запросом вычисляли. Есть решение. Сейчас я его параллельно нашему прекрасному общению набрасываю. Но может быть кто-то даст более красивое...
 
 Рекламное место пустует
   DexterMorgan
 
11 - 25.12.17 - 16:40
как связано продажа 1 и возврат 1? по номеру что ли?
   piter3
 
12 - 25.12.17 - 16:41
(10) Как не связанные доки???
   PiotrLoginov
 
13 - 25.12.17 - 16:41
(9) именно!  Но люди как-то возвращали без указания документа продажи. Не буду кидать камнями в конфу. А то холивар накликаю
   piter3
 
14 - 25.12.17 - 16:41
А при перепроведении,что будет?
   DexterMorgan
 
15 - 25.12.17 - 16:42
почему продажа 3 была 5, а стала 4?
   PiotrLoginov
 
16 - 25.12.17 - 16:42
(11) Регистраторы никак не связаны. Пусть они будут в условии задачи абстрактным полем.
   DexterMorgan
 
17 - 25.12.17 - 16:43
(16) Мля мы тут нейронные сети что ли? как ты получил результат, что за  алгоритм?
   PiotrLoginov
 
18 - 25.12.17 - 16:43
(15) ну как же.  Возврат2 (8 штук) вычел 7 из Продажа2 и 1 из Продажа3, т.е. вычел все, что мог из тех продаж, которые были до него, и из которых есть чего вычитать
   PiotrLoginov
 
19 - 25.12.17 - 16:45
(17)  вот  появляется Возврат1 .  Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится.


вот  появляется Возврат2 .Он вычитает своё колво изо всех продаж, которые были до него, в которых еще есть что вычитать, пока его колво не закончится.
   DexterMorgan
 
20 - 25.12.17 - 16:46
(18) меняй архитектуру системы, это лажа, то, что ты пытаешься сделать запросом
   piter3
 
21 - 25.12.17 - 16:46
(18) А если будет сторно и еще возврат как твой алгоритм будет работать
   PiotrLoginov
 
22 - 25.12.17 - 16:48
(20) см. (7)


(21) сторно какой операции? не стоит заморачиваться принципами ведения учета.  представьте, что вместо Продажа1  написано Измерение1
   DexterMorgan
 
23 - 25.12.17 - 16:48
(21) + задним числом исправят документ
   DexterMorgan
 
24 - 25.12.17 - 16:48
(22) см (20)
   PiotrLoginov
 
25 - 25.12.17 - 16:49
Нет,  лучше "ПолеСобытияУвеличенияОстатка1"
   memogolik
 
26 - 25.12.17 - 16:49
(13) а как понять что Продаже1 соответствует именно Возврат1?
   DexterMorgan
 
27 - 25.12.17 - 16:50
(22) не ну если ты извращенец, на покури http://catalog.mista.ru/public/266377/
   PiotrLoginov
 
28 - 25.12.17 - 16:50
(26) задача - вычесть возвращаемое из переданного покупателю. Показать юзеру, из какой продажи количество какого возврата вычитал запрос - такой задачи не стоит.
   memogolik
 
29 - 25.12.17 - 16:51
Т.е измерения только Клиент и дата?
   PiotrLoginov
 
30 - 25.12.17 - 16:52
(27) там получаются готовые остатки из соответствующего регистра партионного учета. Я же написал, что в реалиях задачи партии типа не ведутся
   Джинн
 
31 - 25.12.17 - 16:52
(19) В нет курсоров, построчно Вы не обработаете запрос. Только извращением с массой временных таблиц, "откусывая" по условиям нужные куски в разные таблицы, а потом объединяя результат. Но тут крыша уедет...
   PiotrLoginov
 
32 - 25.12.17 - 16:52
(29) дату в исходных таблицах вижу.  Клиент  - не вижу.
   DexterMorgan
 
33 - 25.12.17 - 16:53
(30) Мля это такой же принцип, что тебе надо, лол.
 
 
   DexterMorgan
 
34 - 25.12.17 - 16:54
(30) в твоей случае партия - это документ продажи, который "закрывают" возвраты "чтобы хватило"
   PiotrLoginov
 
35 - 25.12.17 - 16:54
(31)  принято.  но щас все-таки уйду в размышления на полчасика


(33) мне это надо. но этого  нет в условиях задачи.  В условиях задачи регистр партионного учета отсутствует.  Все.  Вернусь через полчаса.
   DexterMorgan
 
36 - 25.12.17 - 16:54
(31) Согласен Чистов, тот еще извращенец
   DexterMorgan
 
37 - 25.12.17 - 16:55
(35) ты че издеваешься
   PiotrLoginov
 
38 - 25.12.17 - 17:08
(37) ни в коем случае. в итоге принято решение обрабатывать каждый возврат неким кодом. Можете кидать тапками.
   DexterMorgan
 
39 - 25.12.17 - 17:32
(38) Мне конечно все-равно на ваш овонокод и ваши "подходы" к решению задач, но еще раз для особенных: "партионный" регистр в твоем случае, регистр из (0), партия - документ продажи. в (27) чувак сделал все запросом
   Джинн
 
40 - 25.12.17 - 17:42
(36) Куда деваться, если нет курсоров... Приходится извращаться.
   PiotrLoginov
 
41 - 25.12.17 - 17:49
(39) я пока никакого кода не приводил. за что такие поклепы про "овнокод"? В (27) многоуважаемый "чувак" гипотетическим регистратором списал некоторые партии по ФИФО. Но там в условии нет задачи сделать это для нескольких регистраторов. Ведь когда исчерпано количество из одного регистратора, в моей задаче надо приниматься за следующий.

Я бы вообще не лез делать такое запросом, если бы уже не имел многочисленный опыт работы с остатками запросом по ФИФО.
   PiotrLoginov
 
42 - 25.12.17 - 17:49
(40) "курсоры"... это что имеется ввиду?
   Сияющий в темноте
 
43 - 25.12.17 - 18:03
(42) Курсоры - это текущая выборка в запросе.
В "числом" SQL можно написать хранимую процедуру, которая будет не только обрабатывать каждую стоку запроса, но и будет иметь возможность ссылаться на эту строку.
   Джинн
 
44 - 25.12.17 - 18:08
(41) Там все аналогично :) Замените его "партия" или "товар" на Ваш "регистратор". Главное принцип.
   PiotrLoginov
 
45 - 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
Практически один в один задача Ильдаровича на ИС - есть оплаты - их надо распределить по документам
   PiotrLoginov
 
49 - 25.12.17 - 20:51
(48) там автор исходит из принципа, что есть момент X, до которого все документы оплачены, а после которого - нет.  Посмотрел бы я на него, если бы выяснилось, что некий свежий документ оплаты оформлен таким образом, что оплачивает именно документ из массива после X.
 
 Рекламное место пустует
   PiotrLoginov
 
50 - 25.12.17 - 20:51
+(49) но за ссылку спасибо.  дала пищу для размышлений
   Сияющий в темноте
 
51 - 25.12.17 - 21:18
оплаты еще и по суммам ложаться,то есть,если заплатили 1000,то если среди неоплаченных документов есть документ с суммой 1000,то оплатили именно его.
   PiotrLoginov
 
52 - 25.12.17 - 21:43
(51) точно.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует