Oborotno-saldovaya vedemost

← →
spogi (2006-03-08 20:27) [0]

Zdrasti..
Xocu sozdat ob.-saldovaya vedemost.
primerno:
01.01.01 | +15
05.01.01 | -7
08.01.01 | +22
11.01.01 | +17
22.01.01 | -11
31.01.01 | +28
--------------
itogi: | 64 (Eto ya delayu s pomoshyu Sum.QRExpr)

A vot kak polucit:

s 10.01.01 po 20.01.01

Do perioda | V period | V konec perioda
--------------------------------------
30 +17 47

Pasibki...

← →
paul_k © (2006-03-09 08:23) [1]

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

← →
spogi (2006-03-10 03:30) [2]

Ya koe-cego ciklicheski perebirayu, no vot ne mogu poymat moment. Vot posle Filter, ta chast kotoraya ostaetsya <<Do perioda>> vivoju na otdelnuyu tablicu so skritom filtrom, napr. Ot ... do 10.01.01, dlya etogo skritoy tablici, sozdayu eshe odnu skrituyu QReport, qde v konce polucayu otvet 30 s pomoshyu QExpr, no kak etot 30 vzyat ottuda i vstavit na QReport polzovatelya i eto doljno bit do togo poka QReport2 ne oyavilsya na ekrane, to est BeforePreview...???
ili est druqie varianti resheniya???

← →
paul_k © (2006-03-10 11:42) [3]

> ne mogu poymat moment.

момент чего?
считаем остаток на начало периода InSum и сохраняем его в InSumTmp
получаем запросом обороты по операциям в отчетном периоде в отсортированые по дате-времени операции (OpDate,OpSum)
в цикле по запросу проделываем следующее
OutSumTmp=OpSum+InSumTmp
пишем во временное хранилище
OpDate,InSumTmp,OpSum,OutSumTmp
InSumTmp=OutSumTmp
к началу цикла
Отчет строим по временному хранилищу. Как его организовать в Парадоксе - второй вопрос

← →
vovnuke © (2006-03-10 16:06) [4]

select :BEFORE_DATE, sum(SUMMMA), :BEFORE_DATE+sum(SUMMA)
from table
where (dt >= :DT1) and (dt <= :DT2)
При условии что поле dt обязятельное, и передаются обе границы

← →
paul_k © (2006-03-10 16:13) [5]

и это работает? мдя... сумневаюсь что-то...
итог то нарастающий должен быть.
по каждой записи а не по всей сумме. Двойка вам

← →
vovnuke © (2006-03-10 16:15) [6]

итог, должен быть, как я понимаю, один для всего периода. Или как?

← →
paul_k © (2006-03-13 08:08) [7]

неверно.станлартная форма оборотки
входящий остаток на начало X
дата вход сумма исход
d x s x+s=y
dd y s1 x+s1=yy
.......................
итого sum(s)
исходящий остаток за период YYYY
не видел пока чтоб оную в один запрос собирали, да ещё для парадокса

← →
paul_k © (2006-03-13 08:08) [8]

неверно.станлартная форма оборотки
входящий остаток на начало X дата вход сумма исход d x s x+s=y dd y s1 x+s1=yy ....................... итого sum(s) исходящий остаток за период YYYY
не видел пока чтоб оную в один запрос собирали, да ещё для парадокса

← →
msguns © (2006-03-13 09:42) [9]

Ответ в [3]. Все остальное - от лукавого.

← →
paul_k © (2006-03-13 14:47) [10]

> [9] msguns © (13.03.06 09:42)
> Ответ в [3]. Все остальное - от лукавого.

ну почему от лукавого.. от трепа и т.д..

← →
vovnuke © (2006-03-13 17:04) [11]

ну уж не от трепа, а в крайнем случае от не такого как вы понимания задачи,
Откуда взялась цифра 30 в вопросе, если алгоритм такой как вы написали?
И вообще что надо получить если будет в период входить несколько дат из базы?

← →
msguns © (2006-03-13 17:08) [12]

>vovnuke © (13.03.06 17:04) [11]

Стандарт оборотной сальдовки таков:

Наименование товара Остаток на начало Приход Расход Остаток на конец

Движение дается суммарно.

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

← →
paul_k © (2006-03-14 08:42) [13]

> [11] vovnuke © (13.03.06 17:04)
> ну уж не от трепа, а в крайнем случае от не такого как вы
> понимания задачи,
> Откуда взялась цифра 30 в вопросе, если алгоритм такой как
> вы написали?

> s 10.01.01 po 20.01.01
>
> Do perioda | V period | V konec perioda
> --------------------------------------
> 30 +17 47

30 - входящий остаток (+15-17+22) - все что было ДО 10-го числа
с 10-го по 20-е одна операция, на +17 единиц учета, что и отражено в примере

← →
Danilka © (2006-03-14 10:02) [14]

в local sql есть Case или нет? просто не помню. если есть, то, кажись, можно и одним запросом.
но с каждым месяцем формировацца будет медленнее и медленнее.
что-то типа:
select xxx,
sum(case then move_date < :begin_date when amount else 0 end) begin_amount,
sum(case then ((move_date between :begin_date and :end_date) and (amount>0)) when amount else 0 end) amount_plus,
sum(case then ((move_date between :begin_date and :end_date) and (amount<0)) when -amount else 0 end) amount_minus,
sum(amount) end_damount
from my_table
group by xxx

← →
Danilka © (2006-03-14 10:16) [15]

гы. then / when местами перепутал :))

← →
paul_k © (2006-03-14 10:26) [16]

> [14] Danilka © (14.03.06 10:02)

точно?? проверял? работает? нарастающий итог дает по входящим/исходящим остаткам?
не может быть...
по каждой записи должено идти изменение. то есть если бы автор взял период до 01/02/01 то должно было быть

> 01.01.01 | +15
> 05.01.01 | -7
> 08.01.01 | +22
> 11.01.01 | +17
> 22.01.01 | -11
> 31.01.01 | +28
> --------------
> itogi: | 64 (Eto ya delayu s pomoshyu Sum.QRExpr)
>
>

> s 10.01.01 po 20.01.01
>
> Do perioda | V period | V konec perioda
> --------------------------------------
> 30 +17 47

47 -11 36
36 +28 64
----------------------------------------
и таки в один запрос? Разъясни как детальнее плиз

← →
Danilka © (2006-03-14 10:32) [17]

[16] paul_k © (14.03.06 10:26)
ой, блин, я для оборотно-сальдовой ведомости, согласно теме, запрос написал.. :)
а у автора савсэм не она.

← →
Danilka © (2006-03-14 10:39) [18]

а по теме тоже можно одним запросом, без всяких ХП и врем.переменных.
Но в орокле. :)
а как для парадокса расписано ишшо в [1].

← →
paul_k © (2006-03-14 11:03) [19]

> [17] Danilka © (14.03.06 10:32)

так то что я привел в примере и есть оборотно-сальдовая:) или я опять что-то спутал?

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

← →
Danilka © (2006-03-14 12:36) [20]

[19] paul_k © (14.03.06 11:03)
> так то что я привел в примере и есть оборотно-сальдовая:)
> или я опять что-то спутал?

В каком примере? То, что просит автор, бухгалтера говорят, называецца "Журнал-ордер".

> а, кстати, в оракле как запрос выглядеть будет?

С помощью аналитических функций. Например, sum может выступать как аналитическая функция.
Самый простейший вариант:

CREATE TABLE test2
(id NUMBER(*,0),
tn VARCHAR2(100),
s NUMBER(15,2))
/
INSERT INTO test2
VALUES (1,"ttt",10)
/
INSERT INTO test2
VALUES (2,"ttr",12)
/
INSERT INTO test2
VALUES (3,"tr",5)
/
INSERT INTO test2
VALUES (4,"dd",8)
/

запрос, один из вариантов:
SELECT id, tn, s, sum(s) over(order by id) xxx FROM test2

возвращает:
ID TN S XXX
------------
1 ttt 10 10
2 ttr 12 22
3 tr 5 27
4 dd 8 35

← →
paul_k © (2006-03-14 13:25) [21]

понял то есть сумма идет нарастающим итогом. Отлично
это понятно вполне. а вот чтоб в строке было
SumIn | OpSum | SumOut __________________________________________________________________ <SumOut из предидущей строки> | <сумма операции> | <SumIn+OpSum>

от это не понятно, блин..

>Danilka © (14.03.06 12:36) [20]
>То, что просит автор, бухгалтера говорят, называецца "Журнал-ордер".

нет. Журнал ордер - это сводный документ. Он же просит во-первых, подробных, во-вторых, накопительный

[21] paul_k © (14.03.06 13:25)
SELECT id, tn, sum(s) over(order by id)-s pref_xxx, s, sum(s) over(order by id) xxx FROM test2
:)

[22] msguns © (14.03.06 13:30)
Вобщем, да. Тогда как его обозвать? :)

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

← →
программист (2006-03-15 00:13) [25]

> [23] Danilka © (14.03.06 14:08)

И такое работает? мдя.. а не в оракле такой самолет не летает???? типа в микрософте, сайбейзе?

>>Видимо, кто-то очень "вумный" заказал ему подобый шедевр, в котором "будет все"
А что Вам в этом шедевр не нравится? У нас его называют документ движения товара. Т.е. в одном списке получаем остаток на начало периода, и список всех документов изменяющих остаток, на сколько изменился, какой стал. В системах ресторанского учета - один из самых часто используемых документов.

[25] программист (15.03.06 00:13)
Аналитические функции это чисто орокловая фича, а не стандарт sql, поэтому в других его нет.
По-крайней мере в микрософте точно нет, про сайбейс незнаю, не видел его.

>>Сказать, для чего и кому нужна такая "убывающе-прибывающая" картина ?
Догадываюсь, что скажешь! :)
На самом деле в ресторанном учете не все так просто, там неизбежны постоянные пересортицы, ошибки ввода и т.д. Приходят документы, написано балык 10 кг, (копченый балык(деликатес), балык с.м. и т.д.) не понятно, начинают догонять, выяснять. В барах с винами та же пробемма снабженец ввел одно, в калькуляции поменяли название, бармен выбил другое по цене. Поэтому приходится поднимать движение товаров сверять, местами перепроводить :).

Oborotno-saldovaya vedemost Найти похожие ветки